Skip to main content
What changed in composerID’s documentation, contracts and reference code, newest first.
Updated as changes ship. Vendor-documentation drift is scanned monthly and reported separately.
​
September 2026
  • The docs become a standard Mintlify site. One sidebar in place of five tabs: Get started, Concepts, Guides, Destinations, Upstream connectors, API reference and Resources. The Introduction is a short page with a card grid, the Quickstart goes from minting a sandbox key to a published receipt in five calls, and the endpoint pages are generated by Mintlify from the OpenAPI document. docs.json is hand-maintained rather than generated. The blog leaves the docs site, and the tier table and the question catalogue arrive from the old marketing pages as Tiers and Question types.
  • The API gets its own host. https://sandbox.composer.id/v1 is the sandbox’s address, so that composer.id is free to serve the documentation. The earlier /api/v1 path keeps working.
  • The HTML site is retired. The marketing pages, the HTML docs portal, its stylesheet, images and the five generators that produced them leave the repository, along with the HTML copies of the blog posts. What remains is the Mintlify site and the API. The Intent API document moves to api-reference/openapi.json, and the API host deploys only the code the function needs.
  • The sandbox is hosted, and it issues its own credentials. The reference sandbox runs as a serverless function, so https://sandbox.composer.id/v1 answers without anything to install. POST /v1/sandbox/keys mints a tenant with a personal API key, an OAuth client and a webhook signing key, shown once and expiring together; there is no account and no sign-in. Each tenant sees only the intents it minted, and an inbound webhook is routed to the tenant that minted the intent it names. The API playground on every endpoint page is interactive against it.
  • Every destination is mapped, and “mapped” now means something exact. A destination is mapped when the one field that carries the Intent ID is identified against the vendor’s published API and recorded in both the carrier table the adapter reads and the page’s own mapping, with tests enforcing both. Fifteen platforms leave the roadmap with full pages (Keelvar, Tonkean, Basware, Fairmarkit, Oracle HCM, UKG, Ceridian Dayforce, BambooHR, iCIMS, SmartRecruiters, Bullhorn, Avature, Eightfold, ContractPodAi and Malbek) and the rest flip under the new definition: 52 mapped, none on the roadmap. Carrier fields stay indicative until confirmed at onboarding, and every page says so.
  • Each destination page opens with its integration path. Authentication, the object composerID publishes into, the field the composerID lands on, and back-sync by webhook or polling, all derived from the registry and the carrier table so they cannot drift from the code.
  • Triage can start the lifecycle. POST /triggers/triage/{tenant} takes a signed Triage completion webhook and turns the assessment into an intent. The Intent ID is derived from the assessment response id, so a replayed delivery returns the existing intent instead of a second one; the answers land in the payload through the tenant’s question map, the rank-1 channel becomes payload.channel, and provenance is recorded under payload.source. The sandbox reads the completed assessment from the delivery itself; a deployment with a WorkAuthor connection fetches it.
  • Publish shows its payload. POST /publish accepts dry_run: true and answers with the exact body it would write to the destination, in the destination’s own field names, with nothing written and nothing recorded. Every receipt now carries the payload that was written, and a replay returns the original.
  • The conformance pack covers eighteen claims. One checks that self-serve credentials authenticate their own tenant and that no other credential can read its intents; the newest checks that a dry run writes nothing and that the real publish that follows carries the same payload.
  • The legal set matches the self-serve sandbox. The Privacy Policy, the Terms of Use and the API Terms drop the account and named-person language: a credential set carries no name, email address or organisation, expires 30 days after it is minted and is rate-limited per network address. Annex III of the DPA adds the key-value store behind the hosted sandbox. The End User Terms now give each intake surface its status rather than listing them all as available today.
​
September 2026
  • The developer docs move to Mintlify and are rebuilt to its standard. Every page is native Mintlify MDX: frontmatter with a title, description and icon, Steps for procedures, Tabs for alternatives, Accordions for long reference detail, and diagrams as Mermaid blocks. The hand-authored pages (the upstream connectors, How composerID connects, The life of one Intent, authentication, MCP and the Manuscript API overview), this changelog and the five legal pages are carried over from the HTML portal; the same content now lives here.
  • The blog is carried to Mintlify. The fifteen posts become MDX under a Blog tab, in the index’s reading order. The HTML posts stay the source until the HTML site is retired.
  • The inbound webhook route is in the Intent API document. POST /webhooks/{platform} now appears in the OpenAPI document like every other operation: no bearer token, a required X-Signature-HMAC-SHA256-1 header, a WebhookEvent request body, 202 WebhookAck on acceptance, 400 for a signature or body failure and 404 for an unknown destination or intent. The webhook event schema states the numbered multi-signature header convention that the verifier, the sandbox and the Manuscript API share; the body’s signature property is deprecated and ignored, kept so existing senders still validate. The conformance pack exercises the route against any deployment URL.
  • The sign-in is gone and the field-level detail is open. Sandbox credentials were issued by Deployed on request, with no account widget and no blurred developer gate on provider pages or the Manuscript reference. The Privacy Policy, the Terms of Use and the DPA’s sub-processor list no longer name Clerk or Resend; Mintlify is listed as the documentation host.
  • The marketing site is set to a plain system in step with the docs. White ground, Inter for reading, JetBrains Mono for every identifier, the docs’ blue as the one accent and neutral grey hairlines. The archival plates, the mist ground, the sheet shadow, the serif display type and the logo band’s drift animation are removed.
​
September 2026
  • The blog is redesigned and rewritten in plain English. The index becomes “Workforce systems, in plain English” with audience filters (For everyone · Product & operations · Technical) and a “Start here” trio telling the whole story. Every article now carries an audience pill and, where relevant, a product-status pill: Current product, Research or Design note. Design notes open with a standard box separating what exists today from what the article explores, and articles describing future capability now say could and should, not does.
  • Coverage grows to 37 and the claims get stricter. SimplifyVMS (VMS) and Omnea (procurement orchestration) join as documented destinations. Provider pages now carry a “No developer portal evident” marker wherever no public endpoint reference could be found, and the connection scorecard’s publish path is derived from the same field: Via onboarding instead of an asserted direct API. Events posture on those destinations is poll until delivery specifications are confirmed per tenant.
  • Two plain-English posts. “Integrations in plain English” explains what an integration actually is: the three things any two systems agree on, and the five steps of a publish. “Who pays?” sets out when Deployed pays, when the customer pays, when we invest together, and why an integration is built once and then lives in configuration. The blog stands at fourteen posts.
  • The docs carry the full wordmark. The pen glyph is retired; every documentation page now shows the same composerID wordmark as the rest of the site.
​
September 2026
  • SEO layer. Every indexable page carries structured data (Organization and WebSite on the homepage, BlogPosting on posts, TechArticle with breadcrumbs on generated docs pages), one canonical URL per page, and a description clipped at a sentence boundary. Links to the homepage resolve to one URL.
​
September 2026
  • Phones read everything. The docs portal no longer scrolls sideways on a 390px viewport: cards shrink below their content, code blocks scroll inside their own box, long mono tokens wrap. Measured at zero horizontal overflow across marketing, blog, legal and docs.
​
September 2026
  • The engraved score. The marketing site moves to one shared stylesheet: a warm ground, archival plates behind a single white sheet, Newsreader for reading and JetBrains Mono for every identifier. The homepage hero is the Channel Map itself, drawn from the registry: five staff lines for the five channels, destinations as notes.
  • Authentication documented and implemented. OAuth 2.0 client credentials at POST /v1/oauth/token: an hour-long bearer token carrying only the scopes the client was granted (six scopes, one per capability), 403 insufficient_scope when a route needs more, RFC 6749 error bodies. Personal sandbox keys remain accepted with every scope. The OpenAPI document declares both schemes and the scope on every operation; the sandbox implements them and the conformance pack checks them.
  • Blog. Twelve posts on how composerID works and what building it against real vendor specifications taught us: the Intent ID, decide/publish/execute, preflight, idempotency, the never-sent boundary, chat intake surfaces, the Beeline mapping, reconciliation postures, docs-watch, the conformance pack, the auth model and the vocabulary of the landscape. RSS at /blog/feed.xml.
  • Legal set published. Terms of Use, Privacy Policy, API Terms, End User Terms and a Data Processing Agreement with its Annexes (description of processing, technical and organisational measures, sub-processors, UK Addendum), all under the law of England and Wales and the UK GDPR. The footer links to every one.
  • Conformance pack. The documented /v1 contract as a runnable test pack: fifteen claims (bearer auth, client credentials, every operation routed, id format, version bumps, the preflight gate, deterministic idempotency and replay, the append-only timeline, signed webhooks, passthrough, discovery) run against any deployment URL. The sandbox passes it in CI, so the pack is the acceptance test for the production service.
​
September 2026
  • Docs watch tells blocked from broken. Vendor portals that refuse automated fetches are reported as blocked, with the last verified date, instead of as broken links. Globality citations moved to the vendor’s new documentation locations.
​
August 2026
  • Manuscript API documented. The full record behind every published score: assessments, documents, surveys, workflows and signed webhooks, served by Deployed’s WorkAuthor backend rather than by composerID. Access per programme.
  • Beeline verified against primary sources. Every claim on the Beeline page is now checked against Beeline’s 14 published OpenAPI specifications; the field-level mapping names the real create schema and its required fields, and coverage status is mapped. The page gains a flow diagram and two assurance sections: what crosses the boundary (including what is never sent), and the exact least-privilege scopes requested.
  • Beeline transport proven offline. The reference transport implements the documented behaviour (per-audience 24-hour tokens, scope-error handling, rate-limit backoff, duplicate safety on the request’s own externalId, webhook validate and event-history recovery) against a scripted fake tenant over real HTTP.
​
August 2026
  • The evidence pack is the Compliance File. Renamed from Defence File in all prose; the schema keeps the old name until a versioned rename.
​
August 2026
  • Every diagram works on mobile. Each ships as a landscape and portrait pair; the portrait variant shows the same content, not a reduced one.
​
August 2026
  • ServiceNow joins twice. As a destination and as a communication surface where the diagnostic runs. Provider pages gain connection scorecards; field-level detail moves behind free developer access.
​
July 2026
  • Coverage grows to 35 documented destination pages across VMS, sourcing, orchestration, contract management, ERP, service management, HRIS and ATS, driven from one registry with CI checking for drift.
​
June 2026
  • Runnable sandbox. The documented /v1 surface runs as a sandbox with mock destination tenants and a narrated demo covering create, plan, preflight, enrich, publish, replay, drift and webhooks. Labelled a sandbox everywhere until a real deployment exists.
  • MCP tool surface. Agents mint, preflight and publish Intent Records over the Model Context Protocol; the documented tools mirror the REST operations one for one.
  • Signed webhooks. Outbound events (published, enrichment requested, drift detected) signed with HMAC-SHA256, with replay-safe delivery and an event history to recover from missed pushes.
​
May 2026
  • The Channel Map. Five fulfilment channels (permanent hire, contingent, statement of work, outsourced, AI) become the site’s organising picture: each destination is placed on the channels its publish objects actually support, so a note on the map is a coverage claim.
  • Docs portal. The developer documentation moves into its own shell with a persistent sidebar, per-provider pages grouped by category, and the API dropdown patched from one hardcoded list so navigation cannot drift from the registry.
  • Coverage beyond the VMS. Provider pages extend across sourcing, contract management, ERP, HRIS and ATS: the record lands wherever the decision executes, not only in vendor management.
​
April 2026
  • The adapter pattern. One pattern for every destination: intent, plan, preflight, publish, reconcile. Publishing is idempotent on the Intent ID, so a retried publish updates the original record instead of duplicating it.
  • First provider pages. SAP Fieldglass, Beeline and Workday documented from primary sources, generated from a single registry so the pages cannot disagree with the data behind them.
  • Minimum viable mapping. Each destination page states the smallest set of canonical fields that produces a valid record in that system, with tenant-defined fields called out as a separate gate.
​
March 2026
  • The Intent Record. One neutral record per decision: diagnostics, routing and admin payloads in canonical field names, anchored by an immutable intent_id that fits the client-supplied identifier field of every destination surveyed.
  • The audit spine. An append-only timeline per intent: created, enrichment requested and fulfilled, published, webhook received, drift detected. Events are never edited; a correction is a new event.
  • Schema registry. Versioned JSON Schemas for the Intent Record and its payloads, served from composer.id URLs so a destination can validate what it receives.