One key, and
149 paths.
Every path lives under /api/v1, every request and response body is JSON, and a bearer key is the only credential. No cookies, no sessions, no OAuth.
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.
An expiry between 1 and 730 days, or never
You set the lifetime when you create the key, and never is one of the options. There is no rotate button: to swap a key you create the second one, 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. 284 paths are in it. 135 of those are admin-only and will refuse your key.
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. The ceiling over the whole API is 100 requests a minute, counted per IP address rather than per key, so several keys behind one address share the budget. Individual routes sit below it: sign-in, payments, deploys and key creation each carry a tighter limit of their own, and the response headers tell 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 failures in a row, and you can't switch it back on for an 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.
Eight 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. There is no rotate button, so you create a second key, 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. Creating and revoking keys is the account owner's, as admin or as member, and the refusal sits in the shared auth path rather than in the interface. A team member acting on your account can still read the list of keys you hold: it shows names, prefixes and scopes, never a token.
Is there a rate limit?
Yes. The ceiling is 100 requests a minute, counted per IP address rather than per key, so several keys behind one address share it. Individual routes sit below that ceiling with limits of their own: 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?
No. A key works from wherever it is used, which is why each integration should have its own: 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.