Kenly Developers

Developer portal ​

Kenly translates books into English automatically. You give it a book — a PDF, scanned pages, or screenshots — and it works through the pages one at a time, translating each, with no one in the loop. This portal is where you learn to drive that from your own code.

Everything runs against the /v1 API: a stable set of HTTP endpoints (the /v1 is the version, so your integration keeps working as we add features). Below you'll find the guides that take you from nothing to a working integration, and a full reference for every endpoint.

New here? Start with the Quickstart — you'll make a successful call in a few minutes, with copy-paste curl, JavaScript, or Python.

Guides ​

Step-by-step walkthroughs for the things you'll actually do.

  • Quickstart — go from zero to a real call: check you can reach the API, make your first authenticated request, then translate a book end to end.
  • Authentication & API keys — the two ways to prove who you are (a login token, or a kenly_sk_live_… API key), what each is best for, and how to create a key.
  • MCP server — install the Kenly connector into Claude Code, Claude Desktop, or Cursor, and translate files on your own machine straight from an AI agent — no website visit.
  • Realtime & webhooks — stop asking "is it done yet?" on a loop. Have Kenly tell you the moment a book's status changes, over a live connection or a signed webhook.

Conventions ​

These pages cover the patterns that are the same across the whole API — how errors look, how paging works. Learn each one once and it applies to every endpoint. (Retry-safety needs no learning: a double-submit of a billable call is deduplicated server-side, so a dropped connection never double-charges you — there is nothing to send.)

  • Errors — every failure comes back in one predictable shape, with a stable code you can branch on.
  • Rate limits — how many requests you get per minute, and the 429 response that tells you exactly how long to wait.
  • Versioning — why /v1 only ever grows (never breaks), and how to build a client that stays compatible.
  • Lists & pagination — when a list endpoint hands back a plain array, and when it wraps results in a PagedResult envelope you page through.

API reference ​

The reference is the complete, always-current catalogue of endpoints. Use the sidebar to browse by resource — Projects, Pipeline, Wallet, Auth, ApiKeys, Webhooks, and more.

Each operation page is generated straight from the API's live description, so it can never fall out of step with the real server. A page shows you the parameters, the request and response shapes, an example, which credential you need, an interactive Try-it console, and copy-paste curl / JavaScript / Python samples. A good first call to try is GET /v1/meta — it's public, so it needs no key.

Base URLs ​

Every request goes to one of these origins. Use production for real work; use the local one when you're running the stack on your own machine.

EnvironmentBase URL
Productionhttps://api.getkenly.com
Local dev (Aspire-pinned)http://localhost:5080

The Try-it console targets these same base URLs (they're the API's declared servers), so a request you fire from the browser goes to a real, safe endpoint.

A typical integration flow ​

Here's the shape of a full integration, start to finish. Each step links to its operation page.

  1. Create a project — POST /v1/projects. A "project" is one book.
  2. Start processing — POST /v1/projects/{id}/process. From here it runs itself: batches auto-advance (1 → 5 → 25 → 100 → rest of the book), and the only thing that ever pauses a run is your wallet running low.
  3. Check on it — poll GET /v1/projects/{id}/status, or skip the polling and let the realtime hub or webhooks push updates to you.
  4. Top up the wallet if the next batch would cost more than your balance.
  5. Download the finished translation when the book completes.

Want this same flow with runnable code? See the Quickstart.