Security

Authentication

All API requests must be authenticated:

Servers use an API key: X-Api-Key and X-Api-Secret on 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.

Turn on two-factor authentication and passkeys for everyone on your team.

GET /auth/login-history lists sign-ins to your account with the IP, device, approximate location and method. Entries that may need a second look have suspicious: true, a risk_level of medium or high, and flags explaining why:

Flag	Meaning
`new_ip`	First sign-in from this IP
`new_device`	First sign-in from this browser or device
`new_country`	First sign-in from this country
`preceded_by_failed_attempts`	Several failed attempts shortly before this sign-in
`failed_login`	The attempt failed
`automated_client`	Made by a script or API tool rather than a browser or app
`flagged_by_system`	Marked suspicious by Yativo

curl 'https://api.yativo.com/api/v1/auth/login-history?flagged=true' \
  -H 'X-Api-Key: YOUR_API_KEY' \
  -H 'X-Api-Secret: YOUR_API_SECRET'

Failed requests with a wrong API secret or a revoked API key also appear, with auth_method set to api_key. If you see ones you don’t recognise, revoke the key and create a new one.

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 the X-Yativo-Signature header on incoming webhook requests. This prevents replay attacks and spoofed events.

Node.js

const crypto = require('crypto');

function verifySignature(rawBody, signature, secret) {
  const hmac = crypto
    .createHmac('sha256', secret)
    .update(rawBody)
    .digest('hex');

  return crypto.timingSafeEqual(
    Buffer.from(hmac),
    Buffer.from(signature)
  );
}

Use 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 the Idempotency-Key header to safely retry without risk of duplicate transactions:

curl -X POST 'https://api.yativo.com/api/v1/sendmoney' \
  -H 'X-Api-Key: YOUR_API_KEY' \
  -H 'X-Api-Secret: YOUR_API_SECRET' \
  -H 'Idempotency-Key: your-unique-request-id-abc123' \
  -H 'Content-Type: application/json' \
  -d '{ ... }'

If a request with the same idempotency key succeeds, subsequent requests with that key return the original response without executing the operation again. Keys expire after 24 hours.

Rate limits

Plan	Limit
Default	20 requests per second per business account
Enterprise	Custom

Some endpoints have their own lower limits, such as 30 requests a minute for GET /ip-whitelist/check and GET /auth/login-history. 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:

HTTP status	Meaning
`401 Unauthorized`	Missing or invalid API key or secret
`403 Forbidden`	Valid credentials, but the request isn’t allowed (for example, from an IP that isn’t whitelisted, or an endpoint that can’t be used with an API key)
`429 Too Many Requests`	Rate limit exceeded

Errors use the standard response envelope, with the reason in data.error:

{
  "status": "failed",
  "status_code": 401,
  "message": "Request failed.",
  "data": {
    "error": "Invalid or revoked API credentials."
  }
}

Get Started

Payments

Wallets

Customers & Compliance

Transactions

Products

Developer Tools

Regional Guides

Authentication

API key hygiene

Webhook signature verification

HTTPS only

IP whitelisting

Idempotency

Rate limits

Sensitive data handling

Error responses

​Authentication

​Review sign-in activity

​API key hygiene

​Webhook signature verification

​HTTPS only

​IP whitelisting

​Idempotency

​Rate limits

​Sensitive data handling

​Error responses

Authentication

Review sign-in activity

API key hygiene

Webhook signature verification

HTTPS only

IP whitelisting

Idempotency

Rate limits

Sensitive data handling

Error responses