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.

​
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.

​
A POBO payout, end to end

  1. Register the originator. Create sender with a name, governmentId and country. Keep the snd_ id.
  2. Register the recipient. Ask Get recipient required fields on the standard Partner API which fields the destination currency and rail need, then create the recipient. Keep the rec_ id.
  3. Price it. Generate a quote on a Paywho route. Keep the qut_ id.
  4. Fund it. Create a pre-transaction with the quote, the recipient and — mandatorily — the sender. You get deposit instructions back.
  5. Submit and track. Submit, then get the transaction by its txn_ id. Submitted rows are marked alias=POBO.

​
Conventions

Success payloads are not specified yet. This reference was built from the POBO Postman collection, which carried no saved responses. Requests, parameters and error bodies are accurate; the shape of data in a successful response has not been captured from a live environment. See what is missing.