Skip to main content
Payment on behalf of. You pay a recipient on behalf of a named sender — the originator of the money — and that sender is recorded on every transaction. POBO is a separate surface from the standard Partner API, with three differences that will catch you out if you assume otherwise.

​
What is different

Internal UUIDs are never exchanged on this surface. Every identifier you send or receive is a reference id, and the prefix tells you what it points at.

​
Base URL

Every POBO endpoint lives under /api/v0/pobo.

​
Authentication

The same single header as the rest of the Endl API, and the key must carry the pobo permission.
A key without pobo is rejected with 403, raised at the edge before the request reaches the service. See Authentication.

​
Paywho only

This is the constraint most likely to surprise you. A POBO quote must resolve to a Paywho route. That means either:
  • a Paywho-supported currency on a bank-transfer rail, or
  • INR on BANK_TRANSFER, IMPS, UPI or CRYPTO
Anything that would route through Bridge — USD → EUR over ACH, for example — is refused:
400
Treat this as a routing decision rather than a malformed request — the payload was fine, the corridor simply is not available on POBO. Branch on ERRTXN_1001 in errors[0].code.

​
The sender is mandatory

senderId is required on every POBO transaction, at both pre-transaction and submit. That is the entire purpose of the surface: the payment is made on behalf of a named originator, and the record carries who that was. Before a sender can be used for a payout it needs three things: A sender created without them is accepted, but a payout referencing it will not proceed.
These three are the minimum, not the full set. A corridor can need more from a sender. Ask Get sender fields for the currency and rail you are paying out on — it returns every field that corridor needs, with its validation rules.

​
A POBO payout, end to end

  1. Ask what the corridor needs from the sender. Get sender fields for the payout currency and rail. It also tells you whether the corridor supports POBO at all — poboSupported: false means it does not.
  2. Register the originator. Create sender with the fields that answer asked for. Keep the snd_ id.
  3. Register the recipient. Ask Get recipient fields which fields the corridor needs, then create the recipient. Keep the rec_ id.
  4. Price it. Generate a quote on a Paywho route. Keep the qut_ id.
  5. Fund it. Create a pre-transaction with the quote, the recipient and — mandatorily — the sender. You get deposit instructions back: send exactly source_deposit_instructions.amount to source_deposit_instructions.to_address.
  6. Submit and track. Submit, then get the transaction by its txn_ id. Both return the same transaction object as the standard surface, with nameOrAlias always "POBO". Submitted rows are marked alias=POBO.
The account that is KYC’d and funds POBO for you is the POBO owner — see Get owner.

​
Conventions

​
POBO error codes

Branch on errors[0].code. See Error codes for every code.