Skip to main content
Use this page to track public API changes that affect integrations.

​
July 2026

  • Breaking: agentType on the Agents module is now a campaign type, not a combined template id. Create agent, the agentType filter on List agents, and the agent responses accept and return outreach, inbound, or appointment. What the agent can do moved to a separate field, capabilityIds on create, which takes one or more of appointment_booking, live_transfer, and add_tag. The seven combined ids listed under “Agent types are now a fixed, validated set” below are no longer accepted as agentType; sending one now returns a 400 listing the three valid types. Integrations that send a combined id as system, with no agentType, are unaffected and keep working. See Campaign types and capabilities for the mapping from each old id to its type and capability set.
  • A campaign’s installed capabilities are now readable. Agent responses carry capabilities on the campaign facet, so you can tell what an agent can do without inferring it from a template id. Capabilities also gate outcomes: a call can only end in TRANSFER when Live Transfer is installed, and in SUCCESS or RESCHEDULE when Appointment Booking is.
  • GET /api/agent-builder/agent-types returns three entries, not seven. Outreach and Inbound each carry a templates array listing the starting capabilities you can pass as capabilityIds. Reminder resolves to a single fixed template.
  • The Campaigns and V2 Projects modules still speak the seven template ids. Their agentType is unchanged and still validated against the original set. It names the template a campaign was cloned from, not what the agent can do, and on an agent created with several capabilities it reflects only the first. These modules will be migrated separately; until then, treat agentType on the Agents module and agentType on Campaigns/Projects as different fields that happen to share a name.
  • Appointment Booking is now a documented skill type. It was already installable and has been all along, but the reference omitted it from the skill type set and from GET /api/agent-builder/agents/{id}/skills/library. Both now list it. No behaviour changed; the documentation was wrong.
  • Breaking: call records answer with the canonical field names. A call’s identifier is id and its agent type is agentType. The storage spellings _id and campaignSystem are no longer part of the response. The list payload also no longer carries cached, queryTime, and generatedAt — those described the server’s own caching, not your data, and were never something to build on.
  • Breaking: execution-history responses nest under data and use camelCase. The run summary, node history, runs list, timeline, and graph endpoints previously spread the run store’s snake_case at the top level of the response, which made an internal storage vocabulary the public contract. They now return { "success": true, "data": { … } } with the same camelCase names the rest of the API uses.
  • Campaign workflows can now be addressed by the agent that owns them. A workflow is reachable at /api/agent-builder/agents/{agentId}/campaign/workflow, alongside endpoints to read a digest, append an action to an outcome, switch an outcome, and delete a node. The six project-scoped equivalents under /api/agent-builder/projects/{locationId}/campaigns/{campaignId}/… still work and are unchanged, but they are deprecated: they now carry a Deprecation response header (RFC 9745) and are marked deprecated in this reference. They will be removed in a future release — move to the agent-scoped paths.
  • Fixed: fetching a call by its platform call id. GET /api/call-history/by-call-id/{callId} returned 404 for every call, including ones that exist. It now returns the call.
  • Fixed: excludeReviewed=false no longer excludes. The value was coerced in a way that read any present value as true, so passing false did the opposite of what it says. excludeReviewed now takes exactly true or false, and any other value is a validation error rather than a guess. disposition is also accepted as a repeated parameter again, not only as a comma-separated string.
  • A campaign’s agentType and dialing are validated wherever a campaign is written. The project-scoped campaign routes accepted any string for either field and stored it, after which the campaign read back with agentType: null and no way to tell from the write that anything was wrong. Both fields are now checked against the published sets on those routes too, and an unknown value is rejected with a 400 that lists the valid ones.
  • Agent types are now a fixed, validated set. agentType accepts only appointment_booking, appointment_confirmation, live_transfer, live_transfer_and_tag, live_transfer_and_booking, add_tag, and inbound_receptionist. An unrecognised value is now rejected up front as a validation error listing the valid types, instead of failing later as a not-found. The same set applies to the agentType filter on List agents. The agent type is also always present on an agent response now. It is null when none can be resolved, where it was previously left out of the object.
  • Breaking: the confirmation and reactivation dispatch modes are retired. Neither can be set on a campaign any more: creating or updating with "dialing": "reactivation" (or "confirmation") is rejected with a 400, and the writable modes are now s2l, pd, and s2l_pd. Campaigns created before this still work — they keep their stored mode, keep dialing exactly as before, and still report "dialing": "reactivation" on a read, which is why that value remains in the response schema. What they cannot do is have their dispatch mode re-sent: an update that includes the retired value is refused, so change the mode to a supported one in the same request if you need to edit such a campaign. confirmation had no campaigns left at all and is gone from reads too; it previously surfaced as pd, and no longer does.
  • Breaking: a campaign’s dialing no longer accepts null. Sending "dialing": null when creating or updating a campaign is now rejected with a 400. Omit the field to leave a campaign’s current dispatch mode alone, or, on create, to take the default for the agent type (outbound types default to pd). There is no “clear the dispatch mode” operation, because a campaign without one is inert: it never dials, and it also hides the controls you would use to set it, so it cannot be repaired from the dashboard. Any campaign already storing a null is re-derived to its correct mode on its next write.
  • Breaking: three campaign-workflow action types have been removed. post-webhook, enroll-in-campaign, and requeue-pd are no longer valid values for a workflow node type, and are rejected on write. The supported actions are add-tag, remove-tag, set-field, move-stage, add-note, send-sms, send-email, and book-appointment, plus the if and switch branch nodes. Re-dialling a contact who did not answer is handled by the engine itself and never needed a node. The webhook node’s url, payload, headers, auth, and retry config fields are gone with it, as is the [REDACTED] projection that existed only to hide its credentials.
  • Workflow configs are rejected if they contain an unreplaced placeholder. A node config carrying a stand-in value (REPLACE-WITH-…, CHANGE-ME, or a URL on a reserved documentation host such as example.com) now fails to save. An empty config is still accepted — an unfinished draft is fine, a value that only looks finished is not.
  • Post-call analysis fields are now protected on update. When you update an agent, platform-managed analysis fields (the standard call outcomes and other system-managed fields) are always retained, even if your request omits them. A partial update that sends only your own custom fields no longer removes the managed ones. Only the custom fields you send are replaced.
  • Added public API documentation for launched customer-facing modules.
  • Added bearer API key authentication guidance.
  • Added standard API response and error conventions.