Guides
SupportAPI StatusSubscribe To Updates

API Guidelines

Suggest Edits

Before implementing our API—and especially before going live in production—please confirm the following points to ensure smooth and secure integration.

Card Usage

Make sure to define appropriate validity periods when issuing cards:

  • Use validityPeriod for standard cards.
  • Use validFrom, validTo, and validTimezone for travel cards.

Cards should only be active during their intended period of use. This adds an extra layer of fraud protection and helps control costs.

👉 Terminate any unused cards to prevent unnecessary usage or charges.

API Rate Limits

Auth0 API Endpoints

Fetch a new BearerToken only shortly before the TTL (Time To Live) expires on your machine or instance.
See our detailed guide on authenticated usage.

❗️

We reserve the right to block requests that significantly exceed this limit.

Pliant API Endpoints

You are limited to 900 requests every 5 minutes per IP address.

Exceeding this threshold will result in a temporary block for the originating IP address. If blocked, you'll receive the following response:

HTTP/1.1 429 Too Many Requests
Server: awselb/2.0
Date: Wed, 21 Sep 2022 08:22:06 GMT
Content-Length: 73
Connection: keep-alive
Content-Type: application/json

{
"error": "Sending more than 900 requests in 5 minutes is not allowed"
}

If you are consistently hitting this limit, please contact us with as much detail as possible regarding your use case and we can look into increasing this for you.

Fair API Usage

Use our API responsibly. Excessive or unnecessary load may result in suspension of your API access under our fair use policy.

Batch Endpoints

Our API provides both single-entity and batch endpoints for retrieving card and transaction details. Always prefer batch endpoints when possible to minimize individual requests.

Caching

Implement caching on your end to reduce redundant API calls. This not only improves efficiency, but also enhances your user experience by making data instantly available via your own infrastructure.

Retries on Errors

Avoid retrying failed requests indefinitely.

  • Retry on transient errors (e.g., HTTP 5xx) with reasonable backoff.
  • Do not retry functional errors (e.g., HTTP 4xx).

We strongly recommend logging the requests your application sends. This helps improve error handling over time.

Callbacks

Please adhere to standard HTTP status codes in your callback implementations.

  • We automatically retry failed callback transmissions for up to 1 day, but only if they return 4xx or 5xx status codes.

See our callback documentation for more details.

You can also use the callback log endpoint to view all emitted events based on your subscriptions.
Check the logs first when troubleshooting issues before reaching out to support.

Issues & Support Requests

Before submitting a support request:

❗️

Note: Due to internal data protection policies, we do not log all request payloads

To help us assist you faster, please include a full curl example of your request when contacting us.

📬 For further support, email us at [email protected].

Updated 10 days ago