Skip to main content

Overview

All Daya API requests require authentication using API keys. Each key is tied to a specific merchant and environment (Sandbox or Production)
API keys grant full access to your account. Never share them publicly or commit them to version control.

API Keys

Generating Keys

  1. Sign up at dashboard.daya.xyz
  2. Navigate to API Keys
  3. Generate separate keys for Sandbox and Production

Key Types

EnvironmentPurposeBase URL
SandboxTesting with fake fundshttps://sandbox-api.daya.xyz
ProductionLive transactions with real moneyhttps://api.daya.xyz
Sandbox and Production environments are completely isolated. Data and keys do not cross environments.

Making Authenticated Requests

Include your API key in the Authorization header using Bearer authentication:
curl --request GET \
  --url https://api.daya.xyz/v1/rates \
  --header 'Authorization: Bearer YOUR_API_KEY'

Merchant ID Inference

Your merchant_id is automatically determined from your API key. You never send it in requests. Why?
  • Security: Prevents merchants from impersonating each other
  • Simplicity: One less parameter to manage
  • Isolation: Each key is cryptographically bound to a single merchant
All API responses include your merchant_id for verification purposes, but you never need to send it.

Environment Isolation

For: Integration testing, developmentCharacteristics:
  • Separate API keys from production
  • Simulated NGN deposits
  • Testnet USDC/USDT (no real value)
  • Same API surface as production
  • No KYB required
Use when: Building and testing your integration
Never use production keys in sandbox or vice versa. The API will reject cross-environment requests.

Security Best Practices

  • Use environment variables or secret management systems (AWS Secrets Manager, HashiCorp Vault)
  • Never hardcode keys in source code
  • Never commit keys to Git repositories
.env
DAYA_SANDBOX_KEY=sk_sandbox_abc123...
DAYA_PRODUCTION_KEY=sk_live_xyz789...
Rotate API keys every 90 days or immediately if compromised:
  1. Generate new key in dashboard
  2. Update your application configuration
  3. Verify new key works
  4. Delete old key
All API requests must use HTTPS. The API rejects plain HTTP requests.
Implement client-side rate limiting to avoid hitting API limits:
  • 100 requests per minute per key
  • 1,000 onramp creations per day (see Limits)
  • Log all API calls with timestamps
  • Alert on unusual patterns (spikes in failed requests, geographic anomalies)
  • Review access logs regularly

Error Responses

401 Unauthorized

Missing or invalid API key:
{
  "error": {
    "code": "unauthorized",
    "message": "Invalid or missing API key",
    "details": "Ensure the Authorization header is present and contains a valid Bearer token"
  }
}
Common causes:
  • Missing Authorization header
  • Malformed header (e.g., missing “Bearer” prefix)
  • Invalid or revoked API key
  • Using sandbox key with production URL (or vice versa)

403 Forbidden

Merchant account frozen or suspended:
{
  "error": {
    "code": "merchant_frozen",
    "message": "Merchant account is frozen",
    "details": "Contact [email protected] for assistance"
  }
}
Why merchants are frozen:
  • Exceeded onramp creation limit (1,000/day)
  • Risk or compliance review triggered
  • Manual suspension by operations
If your merchant account is frozen, new onramps, FX conversions, and withdrawals are blocked. Contact support for resolution.

Webhook Authentication

Webhooks use HMAC-SHA256 signatures, not API keys. See Webhook Verification.

Testing Authentication

Verify your API key works:
curl --request GET \
  --url https://sandbox-api.daya.xyz/v1/rates?from=NGN \
  --header 'Authorization: Bearer YOUR_SANDBOX_KEY'
Expected response (if successful):
{
  "rate_id": "rate_abc123",
  "from": "NGN",
  "to": "USDC",
  "rate": 1545.50,
  ...
}

Next Steps