Skip to main content
RaaS uses a tenant api_key on every server-side call. User-scoped operations also require a userToken from the auth routes. Never ship the api_key to mobile apps or public frontends.

​
Credentials at a glance

CredentialWhere you send itPurpose
api_keyHTTP header api_keyTenant authentication and scope enforcement
userTokenPath or body per endpointEnd-user session for contacts, funding, operations
curl -sS -X POST "https://raas-partner-cv.nomas.cash/v1/auth/get-user-token-v2" \
  -H "Content-Type: application/json" \
  -H "api_key: YOUR_SANDBOX_API_KEY" \
  -d '{"email":"sandbox.user@example.com"}'

​
Typical error responses

Auth routes usually return JSON with at least a reason string. Money routes often add code. Treat 400 as a client fix, 401 as a key problem, 404 as missing user, and 500 as retryable with backoff.
Example error body
{
  "reason": "User not found",
  "code": "USER_NOT_FOUND"
}
Store keys in a secret manager, rotate when staff leave or a key leaks, and update all services before disabling the old key.
Your key must include scopes for the surface you call (Partner, Partner Send, Partner Full, etc.). If you receive 403, confirm the key’s scope with Leap.
Some integrations use mutual TLS and a different host. See API overview for the mTLS base URL pattern and certificate usage.
Do not paste real api_key or userToken values into tickets, chat, or public repositories.
Optional encrypted channel: tenants with Request4R send and receive JWE-wrapped payloads under /v1/partners/request4r — see Request4R (JWE encrypted channel).