Skip to main content
The Kamui External API is an HTTP API for vault and wallet data and for vault transactions.
  • Read actions return the Kamui vaults with their live state, each vault’s share price and TVL history, and a wallet’s positions and transaction history across the vaults.
  • Transaction actions quote and build the unsigned transactions that deposit USDC into a vault or create a redeem request on it.
The API never signs or sends a transaction: your users sign and send the transactions it builds, with your own wallet stack.

​
Base URL

Every endpoint page has a Try it playground. It sends real requests to the base URL in its Server section, which defaults to the URL above. Paste your key under Authorization, edit the body, and click Send.To work from Postman instead, download the Postman collection.

​
Requests

  • Call every action as POST <base URL>/<action>, with a JSON object body and Content-Type: application/json. The body may be at most 16 KiB.
  • Send your API key in the x-partner-api-key header on every request. See Authentication.
  • Bodies are strict: an unknown field answers 400, and so does a field named twice in one object.
  • Only POST is allowed. Any other method answers 405.
  • Call the API from your backend only. It sends no CORS headers, and a browser or mobile app must never hold your key.

​
Get started

1

Get an API key

Kamui issues one key per client. Store it in a secret manager: it is shown only once.
2

Check the key

Call health.ping with an empty body. A 200 with "status": "ok" means the key works.
3

Read data

Call vaults.list for the vaults, then the other read actions below. Every success response is { "data": …, "asOf": <Unix seconds> }.
4

Build transactions

Ask Kamui to enable transaction building for your API client. Then quote and build deposits and redeem requests: see Build transactions.

​
Read actions

​
Transaction actions

Both take a type: DEPOSIT (a USDC deposit, syncDeposit) or REDEEM_REQUEST (a redeem request, requestRedeem). Transaction building must be enabled for your API client: until it is, both actions answer 403 actions_not_enabled. See Build transactions.

​
Request ids

  • You may send an x-request-id header: 1 to 128 letters, digits, ., _, : or -. Any other value is replaced with a new UUID.
  • Every response carries the id in its x-request-id header, and every error body in requestId.
  • Quote the request id when you contact Kamui about a request.

​
Limits

Kamui limits the number of requests of each API client per minute. All the keys of one client share its limits. There are two limits, one per group of actions:
  • Kamui sets the limits per client and can change them. The RateLimit-Policy header shows yours.
  • The windows are fixed UTC minutes: each count starts again at the start of the next minute.
  • A request counts once its API key is accepted, whatever the answer. A 400, a 404 route_not_found, a 403 actions_not_enabled and a 503 actions_disabled count too. A request with a missing or rejected key (401) or another method than POST (405) does not count.
  • The two limits are separate. Over the actions limit, the read actions still answer.
Every counted response carries the state of its limit:
  • RateLimit-Policy: the limit (q, requests) and the window (w, seconds).
  • RateLimit: the requests left (r) and the seconds until the window resets (t).
  • X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset (Unix seconds) give the same values.
Over the limit, the API answers 429 with a Retry-After header in seconds, and runs nothing:
  • Wait Retry-After seconds before you send the next request of that limit.
  • Avoid tight polling loops. Space out repeated reads of the same data.
  • If the API cannot check your limit for a moment, the read actions still answer, without the rate-limit headers. The transaction actions answer 503 service_unavailable instead: retry them with backoff.
Ask Kamui if your integration needs higher limits.