Authentication

The minnha API uses static API keys passed in the X-Api-Key header. Keys are scoped to one merchant and one environment, and are encoded in the prefix.

Key format

PrefixEnvironmentWhere to use it
mp_test_…TESTSandbox — no real charges, free to share with QA.
mp_live_…LIVEProduction — real money moves. Treat like a password.

Using a key

bash
curl -X POST https://api.minnha.pay/api/v1/sessions \
  -H "X-Api-Key: mp_test_abc123..." \
  -H "Content-Type: application/json" \
  -d '{"amount": 100, "currency": "SAR"}'
Never expose secret keys client-side. Only the server-issued sessionToken is safe in the browser / mobile. If a key leaks, rotate it from the dashboard immediately.

Environment inference

You do not need to pass X-Environment for API-key requests. The backend infers it from the key prefix and enforces it — a TEST key can never read LIVE data, and vice versa.

Creating keys

From your dashboard: Developers → API Keys → Create TEST / LIVE key. The full key is shown once — copy it into your vault (1Password, AWS Secrets Manager, Doppler...) before closing the dialog.

Rotating keys

  1. Create a new key in the same environment.
  2. Roll your deploy to use the new key.
  3. Once traffic on the old key drops to zero (visible on the Monitoring tab), delete it.

Dashboard auth (OIDC / Bearer)

Dashboard endpoints (branding, roles, members, monitoring) use Keycloak-issued Bearer JWTs. End-users sign in via OIDC; API users should use API keys.