One key, and
plain HTTP.
Every path lives under /api/v1, every request and response body is JSON, and for scripts a bearer key is the only credential you need: no cookie jar, no login handshake, no OAuth app to register.
A key you see once
Keys are prefixed ek_ and stored hashed, so the token is shown when you create it and never again. Lose one and you revoke it and issue another: nothing on our side can read it back to you.
Read or full, and nothing between
A key carries one of two scopes. A read key lists and fetches, a full key creates, changes and destroys. The check runs centrally instead of route by route, so read means read on every path. There is no per-resource scoping: a full key reaches everything your account can, except creating a key or changing a key's IP allowlist, inviting a collaborator or changing their role, adding or removing 2FA, passkeys and connected accounts, exporting your data and closing the account. Those need you signed in to the console.
An expiry you pick, or never
You set the lifetime when you create the key: never, 30 days, 90 days or a year in the console, or any whole number of days from 1 to 730 over POST /api-keys. That call takes the session token signing in gives you, not a key: a full key can revoke keys, itself included, but can't create one. There is no rotate button: to swap a key you create the second one in the console, move your integration onto it, then revoke the first.
Twelve events, signed on the way out
Register an HTTPS endpoint and we POST a JSON envelope when something happens on your account: six instance events, one payment event, one wallet event, two account events and two ticket events. A ping you fire yourself makes a thirteenth, so you can prove the receiver works before you need it to.
The reference is the spec, rendered
/docs/api reads the live OpenAPI document in your browser, so it describes what the API serves rather than what someone remembered to write down. It lists the customer-facing paths only: admin routes are left out of it, and they refuse a customer key regardless.
What a request looks like
The key goes in the Authorization header as a bearer token, and that is the whole of authentication. Nothing is signed, nothing is negotiated first.
curl https://console.ekire.net/api/v1/instances \ -H "Authorization: Bearer $EKIRE_API_KEY"
GET /instances answers with your servers in an items array. Most routes share one budget of 100 requests a minute, counted per IP address rather than per key, so several keys behind one address share it. Sign-in, payments, deploys and key creation each carry a tighter limit of their own instead, counted in a separate bucket that doesn't draw on the 100, and x-ratelimit-limit on each response tells you which one you are against.
What a receiver is promised
Webhook delivery has bounds, and they are the same for every account. These are the ones worth knowing before you point an endpoint at us.
| What | The number |
|---|---|
| Endpoints per account | 20 |
| Endpoints sharing one host | 3 |
| Attempts per delivery | 6, with exponential backoff |
| Timeout per attempt | 10 seconds |
| Auto-disable | After 20 failed deliveries in a row. You can switch it back on once an hour has passed since the first of them, and each re-enable restarts that hour |
| Delivery log | The last 50 per endpoint, purged at 30 days |
Every delivery carries an HMAC-SHA256 signature computed over the timestamp and the body joined by a dot, so recomputing it with your endpoint's secret tells you both that the payload is ours and that it hasn't been replayed under a new time. The URL you save is checked against the same guard that every outbound fetch uses, and checked again at each delivery against the address the socket actually resolved to: your endpoint has to answer on a public address, and we don't follow redirects to reach it.
There is no alert event
Alert policies on CPU, memory and disk fire and resolve by email to the account owner, and that is the only place they go. Nothing sends them to a webhook, a chat room or a pager. If you want them somewhere else, the mailbox is where you have to catch them.
Seven things this API doesn't have
It is REST, JSON and a bearer token. Everything an HTTP client can do, you can do; anything that needs a layer above HTTP, you build yourself.
Questions we get
Is there an SDK, a CLI or a Terraform provider?
No, none of the three. There is the REST API, the OpenAPI document that describes it, and whatever HTTP client you already use.
How do I rotate a key?
By hand, and not with a key. There is no rotate button, and a key can't create keys, so you create the second one in the console, or over POST /api-keys with a session token, move your integration onto it, and revoke the first. Keys are independent of each other, so both work while you switch.
What happens when a read key tries to write?
It is refused. The scope is checked in one place rather than route by route, so a read key is read on every path, including the ones added after you issued it.
Can someone on my team use the API?
Not on your account. Your keys belong to you, the owner: a collaborator acting on your account, whether admin or member, can't create, revoke or even list them, and the refusal sits in the shared auth path rather than in the interface. A key always acts as its own owner, never as a team account, so each person uses keys on their own account.
Is there a rate limit?
Yes. Most routes share 100 requests a minute, counted per IP address rather than per key, so several keys behind one address share it. Some routes have a tighter limit of their own, counted separately from the 100: deploying a server is 10 a minute, creating a key is 10 a minute, and payment calls are 15. Read x-ratelimit-limit on the response rather than assuming the 100.
Is there a sandbox or a test mode?
No. There is one environment. A deploy over the API creates a real server and bills your real wallet, exactly as the button in the console does.
Can I lock a key to one IP address?
Yes. Give a key an IP allowlist when you create it, or edit it later under Settings → API keys. Entries are single IPs or IPv4 CIDRs, up to 50; IPv6 callers list their exact address. A request from any other address gets 403 ip_not_allowed. Leave it blank and the key works from anywhere, so still give each integration its own key: revoking one then costs you nothing anywhere else.
Where are the docs?
Both trees are in the console. /docs is the written guide, and /docs/api renders the live OpenAPI spec in the browser, so every path, field and response you read there is the one the API serves right now.