How this changelog works
Entries are newest first. Each entry gives a date, a change type, and what you need to do. Breaking changes are called out first inside each date block.
Change types:
| Type | Meaning | Action needed |
|---|---|---|
| Breaking | Existing behavior changes or is removed | Yes, before the stated date |
| Added | New endpoint, field, or dashboard capability | No |
| Changed | Behavior differs but old calls still work | Read and confirm |
| Deprecated | Still works, removal date announced | Plan migration |
| Fixed | Defect corrected | No |
API versioning is covered in api-conventions. The version is part of the path (/api/v1). If a change below refers to a request or response shape, that page defines the shape.
What counts as breaking
These are treated as breaking and get advance notice:
- Removing a field from a response, or removing an endpoint.
- Changing the type of an existing field.
- Adding a required request parameter.
- Changing the meaning of an existing enum value.
- Changing an HTTP status code returned for an existing condition.
These are not treated as breaking, and can ship without notice:
- Adding a new field to a response body.
- Adding a new value to an existing enum.
- Adding a new optional request parameter.
- Adding a new webhook event type.
- Changing the wording of an error
messagestring. Thecodeis stable, themessageis not. See api-errors.
The consequence for you: your JSON parsing must tolerate unknown fields, and your webhook handler must ignore event types it does not recognize rather than erroring. A handler that throws on an unknown event type will start failing and get retried on a schedule you did not choose. See webhook-events and webhook-retries.
A tolerant handler looks like this:
import express from "express";
const app = express();
app.post("/finn/webhook", express.json(), (req, res) => {
const event = req.body;
switch (event.event) {
case "call.completed":
handleCallCompleted(event);
break;
default:
// Unknown or newly added event type. Acknowledge, do not throw.
console.log("unhandled event", event.event);
}
res.status(200).send();
});
function handleCallCompleted(event: unknown) {
// your logic
}
app.listen(3000);
Entries
2026-10-17
| Type | Change | Action |
|---|---|---|
| Added | call_flow field on Finns: read and write the call flow, including End Call, Call Transfer and Cal.com tools. Tool API keys are returned as "[redacted]". See Call flow. | None. Tolerate the new response field. |
| Added | POST and GET /finns/{finn_id}/knowledge_base: add documents (text, URL or file) and list them. See Knowledge base. | None |
| Changed | POST /calls now runs the Finn's call flow when it is turned on, as deployment calls do. | Test single calls placed with Finns that have a call flow. |
How to find out before something breaks
Polling this page is the weakest option. Better:
- Keep a staging workspace with a separate API key and run your integration against it before you promote. See local-development for running against your own machine.
- Write your client to tolerate unknown fields and unknown webhook event types, as shown above, so additive changes cannot break it.
Things that change without a changelog entry
Some behavior is per-workspace and will not appear here at all, because it is configuration rather than platform change:
| Area | Where it changes | Page |
|---|---|---|
| Concurrency limits | Your plan and workspace settings | concurrency |
| Rate limits | Per key, per endpoint | api-rate-limits |
| Retention windows | Settings → Data, dashboard only | retention |
| Phone number allocation | Dashboard phone number settings | phone-numbers |
| Agent prompt and voice | Dashboard agent editor | agents-overview |
If a call started failing and nothing on this page explains it, the cause is usually one of the above rather than a platform change. Start at troubleshooting, then check api-errors for the specific code you got back. If neither resolves it, support covers what to include in a report.