Authentication

Kora Remittance uses three credential types depending on who is calling.

Credential	Header	Used by	For
API key	Authorization: Bearer kora_…	Your server	Server-to-server calls scoped to your tenant
Tenant ID	X-Tenant-ID: <uuid>	Your server	Identifies which tenant account the call belongs to
Session token	Authorization: Bearer <jwt>	Your app (end user)	User-scoped calls: create transfer, list own history
Partner key	X-Partner-API-Key: <key>	Your server	Minting a handoff token (see Partner Handoff)

Standard request

Most server-to-server calls send the API key plus the tenant ID:

curl https://api.korastratum.com/api/v1/remittance/corridors \
  -H "Authorization: Bearer kora_abc123..." \
  -H "X-Tenant-ID: 550e8400-e29b-41d4-a716-446655440000"

End-user actions (creating a transfer, listing the caller's own transfers) use the session token the user obtained at login or via handoff — the user id is always taken from the token, never from a parameter, so a user only ever sees their own data.

API key format

Keys are prefixed with kora_ followed by a random token — for example kora_af6fe71cdf85…. A key is issued for a single environment (production or sandbox) and is scoped to your tenant.

warning

Never expose an API key or partner key in client-side code. Both are server-side credentials. End-user clients only ever hold a short-lived session token.

Environments

Environment	Base URL	Use with
Production	https://api.korastratum.com/api/v1/remittance	kora_ production keys
Sandbox	https://sandbox.korastratum.com/api/v1/remittance	kora_ sandbox keys

note

Sandbox and production are separate hosts — send each key to its matching base URL. A sandbox key against the production host returns 401. Confirm your exact base URLs in the dashboard.

Next steps

• Quickstart — Create your first transfer
• Partner Handoff — Mint a session for a user from your backend