Skip to main content
If your team uses the Request API Admin partner self-service portal, the API playground at /portal/playground helps you exercise the public /v1/request-money contract—and, when your operator enables it, first-party remittance status updates—from guided forms before you wire your own HTTP client.

​
What it does

  • Create request-money — Builds a card payout payload (tokenized PAN or token, expiry, cardholder, applicant, and address fields) and sends POST {REQUEST_API_BASE_URL}/v1/request-money using the API key you paste into the playground. Required card fields match the public API: number, expiryMonth, expiryYear, and cardholderName. last4, brand, country, and stateCode on the card are optional, as are stateCode and city on the address; empty optional fields are omitted from the proxied JSON.
  • Get by referenceId — Sends GET {REQUEST_API_BASE_URL}/v1/request-money/{referenceId} for an eight-character alphanumeric referenceId you enter.
  • Update status (internal) — Sends PATCH {REQUEST_API_BASE_URL}/v1/internal/remittances/status with JSON referenceId, status, and optional statusDetails. The admin API sets partnerId from your partner JWT (you do not type it). You never paste the internal bearer secret in the browser; the admin API reads INTERNAL_REMITTANCE_STATUS_SECRET from its environment and must match the value configured on request-api.
The browser calls the admin API POST /api/partner/playground/execute with your partner portal JWT (cookie or Authorization header, depending on deployment). You do not send X-API-Key directly from the browser for that call.

​
How credentials flow

1

Sign in to the partner portal

Authenticate as a portal user linked to your partner record.
2

Pick an operation tab

Use Create request-money or Get by referenceId when you need the bring-your-own-key flow. Use Update status (internal) when your operator configured INTERNAL_REMITTANCE_STATUS_SECRET on the admin API to match request-api; the API key field is disabled for that tab.
3

Paste your active API key (create and lookup only)

For create and lookup, enter the raw integrator key in the playground Credentials card. The SPA keeps it in memory only; it is not written to localStorage or sessionStorage, and navigating away clears it.
4

Run an operation

Each Run sends POST /api/partner/playground/execute with your operation payload. The admin API validates your partner JWT, reads partnerId from the token (never from the body for internal status), then either forwards your call with x-api-key (create and lookup) or Authorization: Bearer plus the server secret (internal status). It returns publicApiStatus, publicApiBody, publicApiUrl, and operation. The admin service does not store or log the raw integrator key beyond what your deployment’s operational logging policy allows.

​
API key rotation

The playground does not rotate your integrator key when you click Run. Your key stays valid until you rotate it explicitly.
To issue a new key, use Account overview → Rotate API key in the portal or POST /api/partner/rotate-key. Copy the new key once, then paste it into the playground if you want to keep testing create and lookup.

​
Prerequisites

  • Partner portal account and sign-in.
  • An active integrator API key that you paste yourself for create and lookup sessions.
  • For Update status (internal), your operator must set INTERNAL_REMITTANCE_STATUS_SECRET on the admin API to the same value as on request-api for that environment. You never receive or paste that secret in the portal UI.
  • Partner documents in MongoDB must include whatsappBaseUrl and whatsappMessageTemplate for POST /v1/request-money to succeed—the same fields request-api enforces. You can set them under Account overview → Messaging configuration in the portal (or your operator can set them via the admin console).

​
Deployment and safety

  • Configure REQUEST_API_BASE_URL on the admin API to the request-api host base URL (no trailing slash, no /v1) for the environment you intend to hit. Banrural sandbox example: https://banrural-request-api-sandbox.up.railway.app (public routes: https://banrural-request-api-sandbox.up.railway.app/v1/...). In hosted environments, point it at non-production request-api when possible: each successful create runs the real flow, including third-party side effects such as identity screening.
  • Configure INTERNAL_REMITTANCE_STATUS_SECRET on the admin API when you want partners to use Update status (internal) in the playground; omit or leave unset only if you disable that path operationally (the admin API returns a clear configuration error when the tab runs without it).
  • The playground is a whitelist, not a generic HTTP proxy: only createRequestMoney, getByReferenceId, and updateRemittanceStatus are supported. Adding operations requires product changes to ExecutePlaygroundDto and the playground service.

​
Limitations

  • The guided create flow is card-only; bank account and cash shapes from OpenAPI are not exposed in the form.
  • The playground’s card and address optional fields follow the same rules as request-api (for example optional last4 / brand / country on the card). Use the API Reference for the full schema if you need every property.
  • referenceId must match the public API: exactly 8 characters from a-z, A-Z, and 0-9.
  • PATCH /v1/internal/remittances/status is not part of the public OpenAPI contract for integrators. You do not call it with X-API-Key from your own backends; the playground exercises it through the admin API for testing and operations workflows your team approves.
Use the API Reference tab for the full CreateRequestMoneyDto surface, 403 screening behavior on create, and GET semantics when no snapshot exists.