Authentication
All API requests must be authenticated:- Servers use an API key:
X-Api-KeyandX-Api-Secreton every request, from a whitelisted IP. - People sign in to the dashboard with an email code or a passkey. Dashboard sign-in only works in the dashboard.
API key hygiene
- One key per system and environment — use separate API keys so you can rotate or revoke one without affecting the others.
- Never expose keys client-side — API credentials belong on your server. Do not embed them in mobile apps, browser JavaScript, or public repositories.
- Revoke after suspected exposure — revoke the key in Developers → API Keys straight away, then create a new one.
- Whitelist the fewest IPs you can — single addresses rather than ranges. See IP whitelisting.
- Store in secrets managers — use environment variables or a dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault, etc.), not plaintext config files.
Webhook signature verification
Always verify theSignature header on incoming webhook requests. This stops spoofed events. The signature has no timestamp, so also deduplicate events to handle replays. See Webhooks.
Node.js
crypto.timingSafeEqual (not ===) to prevent timing attacks.
HTTPS only
The Yativo API only accepts HTTPS connections. Webhook delivery also targets HTTPS endpoints only — HTTP URLs will be rejected on webhook creation.IP whitelisting
Every API key is limited to the server IPs you list on it. See IP whitelisting. To restrict inbound webhooks on your own firewall, contact support for the current list of Yativo webhook IPs.Idempotency
For mutating requests (payouts, deposits, transfers), use theIdempotency-Key header to safely retry without risk of duplicate transactions:
Rate limits
Some plans set their own limit. Enterprise plans have no general limit.
Some endpoints have their own lower limits, such as 30 requests a minute for
POST /exchange-rate and GET /ip-whitelist/check, and 1 a minute for GET /exchange-rates. When a limit is hit, the API returns 429 Too Many Requests with a Retry-After header indicating when to retry.
Sensitive data handling
- Virtual card sensitive details (full PAN, CVV) are returned only on the card detail endpoint and should be displayed in-app temporarily — never logged or stored on your servers.
- Yativo is PCI-DSS compliant. Do not log or store raw card data in your systems.
- Customer PII (names, emails, phone numbers) should be treated as sensitive. Limit access in your systems to only those who need it.
Error responses
Security-related errors you may encounter:
Errors use the standard response envelope, with the reason in
data.error:
error_details object with a stable code, message, fields, retryable and retry_after. Examples on these pages leave it out for brevity. See Error response format.
