Every request to the RemitFlex API must be authenticated using an API key passed as a Bearer token in the Authorization header. There are no cookies, sessions, or OAuth flows — authentication is stateless and key-based. This page explains how to obtain and use your keys, what scopes control access to, and how to handle authentication errors in your integration.
Sending Your API Key
Include your API key on every request using the Authorization header:
Authorization: Bearer YOUR_API_KEY
curl -X POST https://api.remitflex.com/v1/payments \
-H "Authorization: Bearer rf_live_xxxx" \
-H "Content-Type: application/json" \
-d '{"amount": 100, "currency": "USDC"}'
Key Types
RemitFlex issues two types of API key, identifiable by their prefix:
| Prefix | Environment | Description |
|---|
rf_live_ | Production | Moves real funds; use in your live application |
rf_test_ | Sandbox | No real funds moved; use during development and testing |
Never use a live key (rf_live_) in development, test suites, or CI pipelines. Live keys interact with real payment rails and will move actual funds.
Obtaining API Keys
API keys are managed in the RemitFlex Dashboard:
- Log in to your RemitFlex Dashboard.
- Navigate to Settings → API Keys.
- Click Create new key, select the desired scope, and confirm.
- Copy the key immediately — it is only shown once at creation time.
If you lose a key, revoke it and create a new one. Revoked keys cannot be restored.
Key Scopes
Each API key is issued with exactly one scope that determines what it can do. Assign the most restrictive scope appropriate for the key’s intended use.
| Scope | Description |
|---|
read | Read-only access to all resources — suitable for dashboards and reporting tools |
write | Create and modify resources — suitable for most server-side integrations |
admin | Full access, including API key management and account settings — use with care |
Most backend integrations should use write keys. Reserve admin keys for internal tooling where key rotation or account configuration is required programmatically.
read, while creating a payment requires write.
Authentication Errors
When authentication fails, the API returns a JSON error object with an error.code field that identifies the specific failure reason.
Returned when the Authorization header is missing entirely or when the key value is malformed or does not exist.{
"error": {
"code": "UNAUTHORIZED",
"message": "No valid API key was provided."
}
}
Returned when the API key exists but has been revoked. You must generate a new key from the Dashboard.{
"error": {
"code": "API_KEY_REVOKED",
"message": "This API key has been revoked. Please generate a new key from the Dashboard."
}
}
Returned when the API key is valid but its scope does not permit the requested action. For example, using a read key to create a payment.{
"error": {
"code": "INSUFFICIENT_PERMISSIONS",
"message": "This API key does not have the required 'write' scope for this endpoint."
}
}
Best Practices
Following these practices keeps your API keys — and your users’ funds — safe:
Store keys in environment variables. Never hardcode an API key in source code. Use environment variables (e.g. REMITFLEX_API_KEY) or a secrets manager such as AWS Secrets Manager, HashiCorp Vault, or Doppler.
- Never commit keys to version control. Add
.env files to .gitignore and audit your repository history if a key is accidentally committed.
- Use the minimum required scope. A reporting service should use a
read key, not a write or admin key.
- Rotate keys periodically. Revoke and replace keys on a regular schedule and immediately upon any suspected compromise.
- Use separate keys per environment. Use
rf_test_ keys in staging and CI, and reserve rf_live_ keys for production deployments only.
- Monitor key usage. The Dashboard shows per-key request history. Unusual spikes may indicate a leaked key.
