Skip to content

Subaccounts

Create and manage merchant subaccounts for marketplaces and platforms.

Subaccounts (also called Sync accounts) let a platform connect child merchants and route a share of each payment to them automatically. Part of the Sync product.

Secret key required

Creating and managing subaccounts requires the secret key (sk...).

Endpoints

MethodPathDescription
POST/accountsCreate
GET/accounts/{id}Retrieve
GET/accountsList
PUT/accounts/{id}Update
DELETE/accounts/{id}Delete
POST/accounts/{id}/tokenRegenerate the OAuth authorization token

The path is /accounts

This resource is exposed under /accounts, not /subaccountssubaccounts here refers to the product concept (child merchants under your platform), matching the "Sync" product name.

The Account (subaccount) object

idstringoptional
Unique identifier.
referencestring?optional
Your own reference for this sub-account.
sandboxbooleanoptional
`true` for a test-mode sub-account.
capabilitiesstring[]optional
Enabled capabilities for this sub-account (e.g. payment collection).
profileobjectoptional
Free-form profile data about the child merchant.
callbackstring?optional
URL the sub-account is redirected to after authorization.
statusenumoptional
Effective connection status.
payment_statusenumoptional
`active` or `inactive` — whether payment capability is currently enabled.
authorization_urlstring?optional
OAuth URL for the child merchant to authorize the connection (only present before authorization).
masterobject?optional
The parent (platform) team, when loaded: `{ id, name }`.
slaveobject?optional
The connected child merchant team, when loaded: `{ id, name, email }`.
pricingobject?optional
Fee configuration, when loaded: `{ percentage_fee, fixed_fee, max_fee, currency }`.
expires_atdatetime?optional
ISO 8601 expiry of the current authorization, if any.
created_atdatetimeoptional
ISO 8601 creation timestamp.

Creating a subaccount

The pricing object accepts percentage_fee, fixed_fee, max_fee, min_fee (all optional, numeric), and currency (required if any fixed/min/max fee is set):

Create a subaccount
curl https://api.wajub.com/accounts \
-H "Authorization: sk.xxxx" \
-H "Content-Type: application/json" \
-d '{
  "reference": "vendor-482",
  "capabilities": ["payments"],
  "pricing": { "percentage_fee": 10, "currency": "XAF" }
}'

Acting on behalf of a subaccount — the X-Sync header

Once a subaccount is active, the platform can act as it by sending its id in the X-Sync header alongside the platform's own API key. When present and valid, the request runs against the subaccount's team instead of the platform's — resources are created under the subaccount, and its own pricing is applied automatically.

X-Syncheaderoptional
The subaccount's `id` (e.g. `acc_7Yh2Mp`) — not its `reference`. Sent alongside the platform's `Authorization` key.
Create a payment on behalf of a subaccount
curl https://api.wajub.com/payments \
-H "Authorization: sk.xxxx" \
-H "X-Sync: acc_7Yh2Mp" \
-d '{ "amount": 10000, "currency": "XAF", "email": "client@example.com" }'

X-Sync is only meaningful on routes the platform calls with its own key — sending it on /accounts/* itself has no effect on how you manage the subaccount, only on which team the request is attributed to. It is honored across the API; the four resources below additionally require the subaccount to hold the matching capabilities entry:

If the request touchesRequired capability
/payments, /payment-linkspayments
/transferswithdrawals
/customerscustomers
/refundsrefunds

Checks performed, in order

  1. 404 — no subaccount exists for that id.
  2. 403 — the authenticated key's team isn't this subaccount's platform (only the platform that created it can act on its behalf).
  3. 403 — the subaccount isn't active (still pending, or cancelled/expired).
  4. 403 — environment mismatch: the API key and the subaccount must both be live, or both sandbox.
  5. 403 — the subaccount is missing the capability required for the resource being called (see table above).
  6. 403 — for /payments//payment-links and /transfers, additionally blocked if the subaccount's payment_status isn't active (payouts and collection are suspended together, even if capabilities still lists them).