Developers › Reference & tools
Developer Reference Changelog Changes to the public API, the authorization server and the MCP endpoint, dated by the day they reached production. Anything a client can observe from outside is listed here; internal work is not.
API status & versions Four live paths. None is deprecated. Current Live and current: /api/v1 (ingestion, session status, identity lookup and resolution, profiles), /api/v2 (second-generation identity resolution — v1 identity stays available), /idp/* (the OAuth 2.1 / OIDC authorization server) and /mcp (the OAuth-authorized Model Context Protocol endpoint). When a version is deprecated it will be announced here first, with a date, and the endpoint will keep answering until that date passes. Contract changes are also published machine-readably at GET /api/v1/notices .
What counts as a breaking change Treated as breaking Not breaking Removing an endpoint, a field, or an accepted value Adding an optional field to a response Narrowing what an endpoint accepts Adding an endpoint Changing the meaning of an existing field Adding a value to a field documented as open Changing a success status code Rewording an error message — parse the code, never the sentence Read your endpoints from discovery, not from this page Every OAuth URL is published in /.well-known/oauth-authorization-server . A client that reads them at startup survives a move; one that hard-codes them from documentation does not, and finds out in production.
2026 2026-09-28 A missing workspace tag answers like a missing document A conversation record that does not carry your workspace tag is now reported exactly like one that was never written: the session waits the same readiness budget with waitingForSource: true , then fails with the same message, which names your workspace tag and both possible causes. Read processing.errorMessage on the FAILED session. 2026-09-27 Your workspace tag must come first A new session whose first container tag is not your workspace tag is refused with a terminal FAILED whose errorMessage begins Container tag order violation . Write containerTags with your workspace tag first and global_anonymous_pool second. 2026-09-14 Applications can run a workspace's own automations A new scope, automations:run , and with it the first tools on this endpoint that are not the same for every workspace . Tools named automation__<id> are built from that workspace’s own records when you call tools/list , so two applications holding identical grants on different workspaces legitimately see different tools. Discover them; never hard-code them. Each automation publishes its arguments as the tool’s own inputSchema and is validated strictly: a number outside its bounds is rejected rather than clamped, an unknown key is rejected rather than dropped, and a required text field refuses blanks. A success is { ok: true, executionId, result? } , where result carries only the fields that automation declares — never its logs, and never anything it read along the way. This scope is a write, despite reading like a query. An automation can post to a channel, call another system or send a message on the workspace’s behalf — and one that is allowed to act may also queue work the platform carries out minutes or days after your call returns . That follow-up is not in your response, nothing calls you back, and you cannot cancel it. Approving the scope publishes nothing by itself: each automation is published to applications individually, and none is by default. Refusals carry a code and a retryable flag. CONCURRENCY_LIMIT and TIMEOUT are retryable — on the first, the run never started. INVALID_ARGUMENTS and AUTOMATION_FAILED are not. RESULT_TOO_LARGE means the automation ran and only its answer could not be returned, so retrying does the work twice. Exhausting the separate 60-per-minute automation budget is an HTTP 429 with Retry-After , not a tool error. 2026-08-31 Processor refusals list every accepted mode 422 PROCESSOR_REQUIRED and PROCESSOR_UNSUPPORTED carry supportedProcessors , every mode the server accepts as {mode, label} . Branch on that array rather than on a list copied from documentation. Documentation: the API reference's example error sentence still listed three processor modes after the fourth was accepted. The example is now marked as generated per request. 2026-08-28 US life insurance, and a terminal answer for ungraded sessions Processor 3 , LIFE_INSURANCE_US , on every plan: a full line of business with its own calibration, roles and fact set. Its budget is a monthly premium. conformance.level gained NOT_EVALUATED , with a reason and evaluatedAt: null , for a session that finished without a grade (processor 0 never opens its source document). PENDING now only ever means "still in flight", and processor 1 sessions are graded like any full run. 2026-08-21 Following identity pointers with an ingestion key, and one field for names GET /api/v1/leads/{leadId}/context and GET /api/v1/profiles/{profileId} dereference the pointers POST /api/v1/identity/lookup returns, with the same ingestion key. They compose the same answer as the get_lead and get_customer_profile MCP tools, and share the lookup's rate budget. nameUse ( PERMITTED / WITHHOLD ) and nameUseReason on every lookup row, and on each conversation of a customer profile: whether an agent may use a name the person has not given in this conversation. It replaces deriving that answer from the verdict, the band or corroboratedBy . Documentation, Recognise a returning customer : the guide said step 3 always goes through OAuth, and sent callers holding only an ingestion key to MCP, which a key cannot reach. It now sends them to the two endpoints above. Documentation, Recognise a returning customer : the guide treated corroboratedBy: ["contact-phone"] as enough to greet a caller by name — exactly what a household sharing a phone returns. Greet by name only on nameUse: "PERMITTED" . Its test step for a phone-only lookup likewise called the correct POSSIBLE_MATCH a wiring fault. Documentation: a lead becomes searchable by the lookup once a usable fingerprint, email or phone has been extracted from it — not once it is scored, as the guide said. Identity-only records are found too. 2026-08-16 Applications can register their own tools A new scope, tools:write , and three MCP tools behind it: submit_tool registers one of your tools with a workspace so LeadLogiX reads its calls as graded evidence on that workspace’s leads; list_tools reports where each of your registrations stands, carrying the reviewer’s note on anything declined; and verify_tool tells you whether the tool you are shipping still matches what was approved, naming which field names and types differ — never a value. submit_tool is idempotent on the tool’s contract, so re-sending an unchanged definition returns the original submission rather than a second one. A retry after a network timeout costs nothing. The MCP endpoint is no longer read-only. It is still read-only for any token without tools:write , and what the new tools write is a proposal : a submission sits at PENDING , is not loaded by the pipeline at all, and changes nothing until a LeadLogiX administrator approves it. You cannot approve your own. Approval applies only to leads processed afterwards — a lead already scored is never re-read. scopes_supported now includes tools:write . It is absent from the defaults a self-registered client may request, and requires both a workspace grant from LeadLogiX and an approving person who administers the workspace. If the three tools do not appear in tools/list , one of those is missing — read the granted scope from the token response rather than assuming you received what you asked for. Documentation, llms.txt : it said LeadLogiX has no token endpoint. It has had one since the authorization server shipped — /idp/token , with refresh tokens. What does not exist is a client-credentials grant. 2026-08-08 Authorization hardening A client registered ahead of time by an administrator could only obtain openid , whatever scopes it had been configured with — every other scope was dropped in silence. Preregistered clients now receive the scopes they were given. A consent link opened in a browser that was not yet signed in failed after the sign-in with a session error. The interaction now survives the round trip. http://localhost/… is refused as a redirect URI. Plain HTTP is still accepted for loopback, but the host must be a literal loopback address — http://127.0.0.1:PORT/… or http://[::1]:PORT/… . A hostname resolves through whatever the machine's resolver says, which is not a guarantee that the authorization code stays on the machine that asked for it. Granted scopes are capped at consent by three independent limits: what the client is allowed, what the approving person's role permits, and what the workspace has enabled. Asking for more is not an error — the extra scopes are shown as unavailable on the consent screen and are absent from the token. Read the granted scope from the token response rather than assuming you received what you requested. Self-registered clients with no activity for 90 days can be removed. A registration is judged on its own age and on when its authorizations were last used, so a client that is still being called is never reaped — one that holds an authorization nobody has used in 90 days is. Removal is a LeadLogiX platform setting and is off by default; the sweep reports first. 2026-08-07 Standard OpenID Connect An access token obtained with openid and no resource parameter was audience-bound to the MCP endpoint, so /idp/userinfo rejected every token it was ever given. Asking for identity now returns a token that works against UserInfo. Clients that send resource — which the MCP specification requires — are unaffected. Standard OIDC claims on /idp/userinfo and in the ID token, for the profile and email scopes. 2026-08-06 OAuth 2.1 / OIDC authorization server LeadLogiX issues its own tokens: authorization code with PKCE ( S256 required), refresh with rotation, and a consent screen the customer controls and can withdraw. Discovery at /.well-known/oauth-authorization-server and /.well-known/openid-configuration . Dynamic client registration (RFC 7591), token revocation (RFC 7009) and token introspection (RFC 7662). The MCP endpoint at /mcp , authorized by an OAuth token and scoped to exactly one workspace. Protected-resource metadata at /.well-known/oauth-protected-resource lets an MCP client discover the authorization server instead of being configured with it. Nothing older is listed Entries begin where the public developer surface did. For anything earlier, the API reference describes what is live now, which is the only thing a new integration needs.