Partner API reference

Base URL: https://api.sendeasy.cash/v1

All request and response bodies are JSON. Unknown fields in a request body are rejected with a 400 — the API will not silently drop a typo.

A "Collection" debits an end-customer’s Benin mobile money account and credits the result into your own sendEasy wallet. A "Remittance" debits your sendEasy wallet and pays a recipient out via mobile money (Benin), bank transfer (Nigeria), or cross-border mobile wallet (UEMOA/CEMAC/DR Congo). Neither product applies FX conversion — amount and currency are the same on both sides of the operation.

Every operations-API request needs an X-Api-Key header. Get your keys from the partner dashboard after you register — a SANDBOX key is issued automatically and works immediately; a PRODUCTION key can be created once your account is approved (status ACTIVE).

Sandbox keys start with pk_test_, production keys with pk_live_. Treat both as secrets: don’t commit them, and only ever send them from your backend, never from a browser or mobile app.

The dashboard itself (register, login, API key and webhook management) uses a separate Bearer JWT — that’s for the humans on your team managing the integration, not for the operations API your servers call.

Every operation created with a SANDBOX key is fully simulated — it never touches a real MTN, B-MO, or bank rail, and never shares sendEasy’s own production credentials or quota. A simulated collection or remittance sits at PENDING for a few seconds (so your polling and webhook-handling code gets genuinely exercised), then resolves to SUCCESS.

This means you can build and test your entire integration — requests, polling, webhooks, error handling — without ever moving real money or needing real recipient accounts.

Every error — validation failures, auth failures, not-found, or an unexpected server error — is returned with the same envelope shape.

partnerReference is your own idempotency key, required on both create-collection and create-remittance and unique per partner (not globally). If you POST the same partnerReference twice, the second call returns the already-existing operation unchanged instead of creating a duplicate — safe to retry a request after a timeout without double-charging or double-paying out.

The reference field in the response (e.g. "PO-2026-00012345") is sendEasy’s own identifier — use it, not partnerReference, when calling GET /partner/operations/:reference.

Debits an end-customer’s Benin mobile money account for the given amount and credits your sendEasy wallet once it succeeds. Processing happens asynchronously — the response is always status PENDING; poll GET /partner/operations/:reference or wait for a collection.succeeded / collection.failed webhook.

Debits your sendEasy wallet and pays a recipient out. Which fields are required depends on destinationRailType — the three supported types are shown below. Like collections, this is asynchronous: the response is always status PENDING, and the debit is reserved upfront so two concurrent requests can’t overdraw your balance.

If your wallet balance is too low, you get an immediate 400 (“Insufficient {currency} balance”). In the rare case the balance check races with another debit, the reservation itself is refused and the operation fails asynchronously (status FAILED, a remittance.failed webhook) rather than returning a synchronous error.

Requires momoOperator and momoNumber. destinationCountry must be "BJ" — mobile money payout is not yet available for other countries.

Requires bankCode and bankAccountNumber (bankName is recommended for display purposes). destinationCountry must be "NG".

For payouts to a mobile wallet outside Benin/Nigeria — UEMOA (BF, CI, GW, ML, NE, SN, TG), CEMAC (CM, CF, TD, CG, GQ, GA), or DR Congo (CD). Requires momoNumber as the recipient’s wallet number, plus the real individual sender’s identity: senderFullName, senderPhoneNumber, and senderCountryOfResidence are mandatory (our upstream compliance partner requires the actual sender’s KYC for this rail, not a corporate/partner identity) — senderNationality, senderDateOfBirth, senderIdType, senderIdExpiryDate, senderAddress, and senderCity are optional but recommended, since missing fields may cause the payout to require manual review. recipientComplianceProfile is an optional free-form object for any additional recipient-side compliance fields.

Looks up a collection or remittance by its sendEasy reference (the value returned as reference when you created it). status is one of PENDING, PROCESSING, SUCCESS, FAILED — poll this if you’d rather not rely on webhooks, or use it to reconcile after a webhook arrives.

Configure a webhook URL from the partner dashboard (or override it per-request with callbackUrl). sendEasy POSTs a signed JSON payload to it when an operation reaches a terminal state — event is one of collection.succeeded, collection.failed, remittance.succeeded, remittance.failed.

Deliveries are retried up to 8 times with exponential backoff (starting at 10s) until your endpoint returns a 2xx. Every attempt — success or failure — is visible in the delivery log on your dashboard, and you can manually trigger a redelivery from there.

Verify every delivery: recompute the HMAC-SHA256 of "{timestamp}.{raw request body}" using your webhook signing secret (shown once at registration, or rotatable from the dashboard), and compare it to the v1 value in X-SendEasy-Signature using a constant-time comparison. Reject anything that doesn’t match, and reject deliveries with a timestamp too far in the past to guard against replay.

Collections (debiting an end-customer) are Benin-only today, via MTN, Moov, Celtiis, or a B-MO/BestCash-linked wallet.

Remittance payouts: mobile money is Benin-only; bank transfer is Nigeria-only; the cross-border mobile-wallet rail covers Burkina Faso, Côte d’Ivoire, Guinea-Bissau, Mali, Niger, Senegal, Togo, Cameroon, Central African Republic, Chad, Republic of the Congo, Equatorial Guinea, Gabon, and DR Congo. Reach out to sendEasy support if you need a corridor that isn’t listed — coverage expands regularly.