Skip to content

Changelog

What changed in the Partner API and these docs.

2026-10

  • AI apps can manage repeat payments. Three new MCP tools: list_schedules, create_schedule (every month or every week, to a saved recipient in India) and change_schedule (pause, resume or cancel). They need the new scope schedules:manage; an app connected before this change asks the customer to connect again. The AI app still cannot pay: each due day sends the customer a pay link on WhatsApp, which they pay on the SmartRemit pay page with their code. The portal shows which app set up each repeat payment. See AI apps (MCP).
  • One docs site. These guides and the API reference are now the SmartRemit docs at smartremit.ai/docs, linked from the site header. They replace the older single-page partner guide, whose content moved into the guides and the API reference. Old links to the preview address go to the same page. New sections: Getting started (where SmartRemit is today, creating a transaction) and Webhooks (the compliance block, client_reference and payout_reference).
  • AI app sign-in fix. Allow on the SmartRemit sign-in page now connects the app. Before, the page answered "This link does not work".
  • AI apps can prepare a transfer. Two new MCP tools: prepare_transfer prepares a transfer to a saved recipient and returns the pay link, and cancel_prepared_transfer cancels one that is not paid. They need the new scope transfers:prepare. The AI app still cannot pay: the customer pays on the SmartRemit pay page with a code sent to their WhatsApp, and the page says which app prepared the transfer. A prepared transfer pays only the recipient's saved account; nobody can change the account on the pay page. Customers can also send disconnect apps to SmartRemit on WhatsApp or Telegram. See AI apps (MCP).
  • AI apps (MCP), early access. A SmartRemit customer can connect Claude, ChatGPT or Perplexity to their own account through SmartRemit's MCP server, for invited customers only. The tools look up quotes, send limits, saved recipients (masked) and the customer's own transfers. They cannot send or pay. See AI apps (MCP).
  • Reason for "other". When purpose is other, POST /transactions now requires purpose_detail: the sender's reason in their own words, 10 to 120 characters that say what the money is for. A missing, too short, too long or meaningless value is refused with 422 before the Idempotency-Key is bound, so a corrected retry with the same key succeeds. When the reason names one of the other purposes (for example "school fees"), the transaction takes that purpose and keeps the reason. With any other purpose, purpose_detail is ignored. It comes back as purpose_detail in every answer, to the partner that owns the transaction only (null when none was given). SmartRemit checks every reason, and some transactions are held for review (compliance_status flagged).
  • Required purpose. POST /transactions now requires purpose: why the money is sent, one of family_support, gift, education, medical, savings, bills, business or other. A missing or unknown value is refused with 422 before the Idempotency-Key is bound, so a corrected retry with the same key succeeds. It comes back as purpose in every answer (null on a transaction made before this change) and is in the settlement instruction's compliance object. Sandbox transactions need it too.
  • New documentation preview. These guides and an API reference generated from the Partner API's OpenAPI description.
  • Order references. Send your own order number as client_reference when you create a transaction. It comes back in every answer and in the settlements statement, and it is in the settlement instruction when your own rail pays the transaction out. A paid_out status callback may send payout_reference (for example a bank UTR); it is saved once and returned as payout_reference.

2026-09

  • Test keys and scopes. Keys are now live (sr_live_…) or test (sr_test_…), and each endpoint needs one scope. A test key works only with sandbox transactions, which never reach a real payout rail.
  • Per-key rate limit. Each key now has its own per-minute budget, inside the per-partner one.
  • Settlements statement. GET /settlements lists your paid and delivered transfers for reconciliation, as JSON or CSV.
  • Timestamped signatures. Instructions and callbacks are signed with x-smartremit-signature (timestamp plus HMAC), with an overlap window when a secret is rotated. The older x-signature header is deprecated.
  • Compliance block. Settlement instructions carry an additive compliance object.
  • Sender name. A transaction created without sender.name is held for manual review.
  • Idempotency hardening. The transaction is bound to its Idempotency-Key before it is created, reserved key prefixes are refused, and a masked payout account is refused.
  • Unpaid expiry. A transaction left unpaid is cancelled after a fixed period.
  • Exchange rates fail safely. A quote or transaction is refused with 503 rather than priced on a stale or missing rate.
  • Settlement endpoint rules. Settlement endpoints must be public HTTPS hosts; redirects and acknowledgement sizes are limited.

2026-06

  • Partner API v1. Key authentication, per-partner rate limit, and the corridors, quote, beneficiaries and transactions endpoints.
  • Webhook-driven settlement. Signed settlement instructions to your rail and signed status callbacks back, with automatic retries.
  • Rates. PUT /rates and GET /rates let you push a wholesale rate per corridor.
  • Any-to-any corridors. destination_country on quotes and transactions.