Security & Access
This page explains, at a high level, how callers are authenticated and what limits apply — so you know what to expect at the gateway before you write a line of integration code. The exact request formats live in the Authentication and API reference sections; here we focus on the model.
Every request passes the gateway
There is a single ingress point. Before any request reaches the platform, the gateway applies a set of identity and policy checks. If any check fails, the request is rejected at the gateway and never reaches the platform or custody.
Depending on your security profile, the gateway enforces:
- Transport security (TLS) on every connection.
- Authentication — JWT, mTLS, or API key (see below).
- A client certificate, where higher assurance is required.
- An IP allow-list for your registered network ranges.
- Rate and usage limits per client.
How integrators authenticate
As a third-party integrator you have a few mechanisms available, used together depending on your security profile:
| Mechanism | What it is |
|---|---|
| OAuth2 client credentials → JWT | You exchange client credentials for a short-lived bearer token, then send it on every request. |
| mTLS client certificate | A client certificate is verified against a trusted bundle for mutual TLS — required for higher-assurance clients. |
| API key | A direct secret for specific machine-to-machine surfaces. |
| IP allow-list | Your calling system's network ranges are registered with the operator. |
Admin and User UI callers authenticate differently (interactive JWT sessions), but as an integrator you'll use the machine-to-machine mechanisms above.
Rate and usage limits
Each client has its own budget — request rate and periodic usage quotas — enforced after identity is established. Design your integration to:
- Back off and retry on rate-limit responses.
- Batch where the API offers bulk modes (e.g. migration) instead of many single calls.
- Cache tokens and infrequently-changing reference data on your side.
Boundaries you can rely on
- You reach only the public Integration API. The platform internals and the custody service are never directly accessible.
- Private keys never leave custody and are never exposed to integrators.
- Personal data is minimized. Where supported, opaque external identifiers can be used instead of personal information (relevant for KVKK / GDPR compliance) — see the Migration section for an example.
Before you go live
A short pre-flight checklist:
- Obtain client credentials (and an mTLS certificate if required).
- Register your source IP ranges with the operator.
- Confirm test vs. production base URLs and the target blockchain network.
- Stand up a webhook endpoint for asynchronous callbacks.
- Verify your rate/usage budget matches your expected traffic.