Skip to main content
Two endpoints sit under everything else Keenable ships — the CLI, the MCP server, and every integration call one or both of them. Reach for the HTTP API directly when you are building something none of those cover.

​
Base URL

​
Authentication

There are two ways in, and the one you pick decides the path you call. With an API key, in the X-API-Key header:
Authorization: Bearer keen_<your_key> works too, and X-API-Key wins if both are present. See Authentication for obtaining and rotating a key, and for the error responses both endpoints share. Without one, on the /public twin of each endpoint:
X-Keenable-Title names the application making the call. It is required on the public endpoints — a request without it is rejected with 400 Missing app identifier — and it is how keyless traffic is attributed. Values longer than 256 characters are truncated, and ?keenable_title= carries the same value when a header is not an option. Parameters and response shapes are identical on both sides, so moving between them means changing the path and swapping one header. This keyless tier is what the CLI, the MCP server, and every integration fall back to when no key is configured.

​
Endpoints

Each endpoint page carries the full request and response shape, examples in curl, Python, and TypeScript, and a playground you can call with your own key.

​
Limits and billing

Authenticated requests are rate limited per organization rather than per IP — see Rate limits for the numbers — and draw on your credit balance. Keyless requests are limited per IP instead, on a public pool capped at 1,000 requests per hour and 10 per second, and they consume no credits. Responses carry X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset, and a 429 adds Retry-After. That pool is shared with everyone else on your egress address, so its headroom is outside your control: use a key for anything past a first look.