Changelog

What changed, and on what date. Breaking changes are announced before they ship.

2026-08-07: numbers, and the permissions that open them

• GET and POST /v1/customers/{id}/numbers, GET and DELETE /v1/customers/{id}/numbers/{number_id} are documented. Rent a number in your customer's country for $15 a month, or display a number they already own as a caller ID for $12. See the numbers reference. The endpoints have been answering since websites shipped; this is the first time they appear here, which was our omission.
• Changed, and worth reading if you already call them. These four now require numbers:read and numbers:order, the permissions that have been in the console and on the authentication page all along. Until today they checked customers:read and customers:write instead, so the permission you were offered was not the permission we enforced.
• Nothing of yours stops working. Every existing key that held customers:read was granted numbers:read, and every key that held customers:write was granted numbers:order. No key gained anything it could not already do. What is new is that you can now take those two away on their own: a key that shows a customer their number without being able to rent one, or lose one.
• Releasing a number is on numbers:order rather than numbers:read. It spends nothing, but it is the one irreversible thing this resource does.
• Also newly documented: GET /v1/customers/{id}/websites/{build_id}, the single website read. It is what to poll after an order. Unchanged, and on sites:read as before.

2026-08-06 — websites

• New: GET and POST /v1/customers/{id}/websites — order a finished, hosted one-page website for a customer. $350 once, then $20 a month from the day it goes live. Your customer never sees us. See the websites reference.
• New: DELETE /v1/customers/{id}/websites/{build_id}, POST .../revision and POST .../domain — cancel with a full refund while nothing has been delivered, spend the one included revision, and get the single CNAME record that points your customer's own domain at their site.
• Hosting bills from go-live, not from order, so a build that takes three weeks costs you nothing for three weeks. The build fee is charged when the order is accepted and refunded in full if the site is never delivered — as a refund line in your ledger, not as a charge that quietly never happened.
• If a month cannot be taken, the site keeps serving for 14 days, then goes offline rather than away for a further 90. Both dates are on the record and in the event before either happens. Topping up during either window brings it back at the same address.
• New permissions: sites:read and sites:order. Existing keys are unaffected — grant them in the console on the keys you want to be able to spend on builds.
• New events: website.ready, website.live, website.failed, website.hosting_due and website.suspended.

2026-08-04 — the assistant, in your own product

• New: POST /v1/chat — an AI sales coach your customers' staff can talk to from inside your front end, under your name. It knows how that one business's calling has actually gone over the last 30 days, and it will not name any company that supplies you. See the assistant reference.
• New: POST, GET and DELETE /v1/customers/{id}/sessions — mint a short-lived session token for one named person, list the live ones, and revoke by your own end_user_ref when somebody leaves. Sessions are what let this run in a browser without your API key ever going near one.
• A session sees a single customer, carries no permissions, expires in 15 minutes by default (an hour at most) and stops after 200 messages. Revocations, a paused customer and a suspended account all take effect on the very next message, not at the next mint.
• Charged per answered message at the rate on the rate card. If the assistant cannot answer, you are not billed for it. Nothing about your existing rates changed.
• We store no transcript. You send the recent turns with each message and keep the thread yourself.

2026-08-04 — reporting

• Reports in the console, over the last 7, 30 or 90 days: what you spent and on which days, how your calls went, which of your customers are actually using it, and how the integration itself is behaving.
• “At current burn, this balance lasts until Friday 14 August.” Projected from the average across the window rather than yesterday, so one busy campaign does not tell you that you run out tomorrow. If automatic top-ups are on, or nothing has been spent yet, it says so instead of inventing a date.
• The connect rate counts calls that have finished, not calls you have queued — a lead waiting in the queue has not failed to reach anybody. Anywhere there is not enough data yet, you get a dash rather than a zero, because those are different claims.
• Integration health: request volume, error rate with the reasons behind it, typical handling time, and webhook delivery success. A delivery still retrying is shown as retrying, not as a failure.
• CSV exports of the ledger, your calls and your customers for the same window. Every figure on the page is counted in UTC days, so two people in different countries reading the same account see the same numbers.
• No API change.

2026-08-04 — self-service top-ups

• You can add funds yourself, by card, from the console — at any hour, without emailing anybody. The bonus your top-up earns is shown before you pay, not discovered in the ledger afterwards.
• Automatic top-ups. Set a balance to watch and an amount to add, and the card on file is charged when you cross it. A declined card is retried with growing gaps and then paused, with an email — never asked over and over.
• Every card top-up produces an invoice. Nothing about your existing balance, rate card or bonus tiers changed; this is a new way to pay, not a new price.
• No API change. Adding funds is a console action on purpose: an API key that could charge a card would turn a single leaked key into a bill.

2026-08-04 — outbound events and webhooks

• Kleos now POSTs a signed JSON envelope to a URL of yours when something happens: call.completed, appointment.booked, customer.ready, balance.low and key.rotated. Endpoints are created in the console. See Webhooks.
• Signed with Standard Webhooks, so any off-the-shelf library verifies it. Rolling a secret keeps the old one signing alongside the new one for a grace window you choose, so there is no gap in which legitimate events are rejected.
• The data in an envelope is the same object the matching GET returns, built from the same code. A handler written against the API works unchanged against the webhook.
• GET /v1/events and GET /v1/events/{id} on the existing events:read permission — a webhook is never the only copy, so an endpoint that was down or did not exist yet is recoverable by reading forward. See Events.
• Failed deliveries retry six times over about eight hours, then wait in the console with their status code and a button to send them again. 410 Gone is the one response that stops the retries early; a 404 does not, because a healthy endpoint 404s mid-deploy.
• Additive change to calls: GET /v1/calls now returns the same full shape as GET /v1/calls/{id}, including finished, recording_url and transcript_url. Nothing was removed.

2026-08-04 — appointments

• GET /v1/appointments and GET /v1/appointments/{id} — the meetings your customers actually got, as their own resource rather than something to reconstruct by walking every call. Filter with customer_id, status, and from/to for a billing period.
• Each row carries call_id, so the appointment_id on a call now resolves to something. Both start_at/end_at (exact instants) and timezone (what the meeting was agreed in) are returned — you need both to show your customer the right hour.
• No new permission: an existing calls:read key reads these today. A booking is the outcome of a call, and a key trusted to read one is trusted to read the other.

2026-08-04 — calls, provisioning and customer onboarding

• POST /v1/calls — queue a business to call. Returns a call_request: Kleos picks the moment, inside that number's legal calling window. See Calls.
• GET /v1/calls and GET /v1/calls/{id} — outcomes, durations, summaries, recordings, transcripts and the appointment if one was booked. view=requests shows what you asked for rather than what happened, and one id works for either kind.
• DELETE /v1/calls/{id} — cancel while still queued. Once claimed you get a 409, never a silent success.
• GET and POST /v1/customers/{id}/provisioning — what is still being set up and who owes the next move (waiting_on).
• POST /v1/customers/{id}/onboarding_link — a link, branded as you, through which your customer accepts the calling terms themselves. See Onboarding your customers.
• New blocker: readiness now reports customer_not_attested until that link is completed. It is the one condition neither money nor a Kleos admin can clear.

2026-08-04 — billing, limits and caps

• GET /v1/balance — spendable balance, held money, and the per-minute rate in force right now, with the full tier table so nothing has to be hard-coded.
• GET /v1/usage — the itemised ledger, each line carrying the customer_id it belongs to. Test-mode lines are returned with applied: false.
• GET and PATCH /v1/customers/{id}/limits — per-customer daily and monthly spend caps, and a per-customer concurrent-call ceiling.
• Rate limiting is now enforced, with x-ratelimit-* headers on every response and Retry-After on a 429 rate_limit_exceeded.
• Calls now reserve money when they start and settle for the minutes actually used when they end. A hold whose call never reported back is released automatically.
• Low-balance warnings at 25%, 10% and zero, mirrored as low_balance on the balance endpoint. The published rate card is on the pricing page in full.

2026-08-04 — first release

• Accounts and keys: kls_live_ / kls_test_, scoped permissions, optional IP allowlists and expiry, self-service rotation with a 24-hour grace window.
• GET /v1/me — account, mode, permissions and limits.
• GET and POST /v1/customers, GET /v1/customers/{id}, with external_ref usable anywhere an id is.
• GET /v1/customers/{id}/readiness — coded blockers for live calling.
• GET and PATCH /v1/brand.
• Idempotency keys on every write, replayed for 24 hours.
• Console at console.kleos.click: keys, the go-live checklist, and an activity log including refusals.

Next

Both things this section used to list, ordering numbers and the assistant, have shipped and are dated above. Nothing is listed here again until it is being built, because a roadmap on a changelog is read as a commitment.

Versioning policy

Additive changes — a new field, a new endpoint, a new optional parameter — ship without notice, so parse responses tolerantly and ignore fields you do not recognise. Anything that removes or changes the meaning of something you already receive is announced here first, with a date, and never lands the same week it is announced.