Skip to main content
This page describes how a published decision gets into a destination system: the five transports, the minimum a destination must offer, and where cost or a configuration change can arise. It is for integration leads and architects planning a deployment. Every destination is different. Some expose open developer APIs, some licence API access separately, some accept no inbound push at all, and some tenants are configured so strictly that no integration can create a record until the configuration changes.

​
Every path carries the Intent ID

Whichever transport a deployment uses, the record that lands in the destination carries the same intent_id, and the publish receipt lands on the same audit spine: the append-only intent timeline that every step composerID takes is written to. The transport is an implementation choice, not a different product.
The Intent API (api.composer.id/v1) is composerID’s own REST contract, and it is the name this page and the rest of these docs use for it. Today it is served by the reference sandbox; the production service behind api.composer.id is in build. See the API reference.

​
The five connection methods

The methods are ordered by how much of the loop composerID runs for you. A deployment can mix methods per destination, and the Channel Map, the rules that say which kind of work goes to which destination, records which method each destination uses.
The default. composerID’s adapter authenticates to the destination’s own API, maps the canonical intent through the tenant’s MappingProfile, the template that translates canonical fields into one destination’s API dialect, and writes the record idempotently. This gives the best fidelity: native objects, native validation, and external IDs returned on the receipt.
On some enterprise platforms API access is licensed separately. Confirm what the client’s contract includes before planning a machine path: see when the client incurs cost.
composerID emits HMAC-SHA256-signed events to endpoints you register: middleware, an iPaaS trigger, or a reporting suite. The Intent API declares four outbound events (vms.requisition.updated, vms.assignment.updated, vms.timesheet.updated, vms.connection.revoked). Publish receipts, drift reports and enrichment gaps are not among them: you read those from the API and the timeline instead. Your side decides what happens next.
Webhooks reach systems you control. Most destination platforms expose no general inbound webhook endpoint for record creation, so the write into the destination still happens through method 1, 3 or 4.
Your integration team calls the Intent API at api.composer.id/v1 to read intents, receipts and timelines, then handles the last mile in code you own. This is the right shape when an internal platform team already runs destination integrations.
Reconciliation becomes your responsibility. Poll the timeline or subscribe to webhooks (method 2) so drift is caught.
composerID triggers a recipe on the integration platform the client already runs (Workato, MuleSoft Anypoint, Boomi, SnapLogic, Celigo, Tray.ai, Microsoft Power Automate / Logic Apps) and the platform’s certified connector performs the write. Unified-API layers (Merge, Apideck) and lighter tools (Zapier, Make) fit smaller estates. Procurement orchestration platforms (Zip, ORO Labs) can also carry the publish as part of an orchestrated flow.
Recipe volume consumes the client’s iPaaS subscription, and connector coverage and field depth vary by platform and tier.

​
Choosing per destination

The choice is made once per destination during connection, recorded in the Channel Map, and revisited only when the destination’s posture changes. Use method 1 where the licence allows it, method 4 where an iPaaS already owns that system, and method 5 wherever a machine path is not viable yet. Each destination page states the posture that can be defended from that vendor’s documentation.

​
What composerID asks of a destination

There is a minimum contract for a destination to sit on the automated path, and a defined fallback when it cannot. The target for any destination of record is Tier B or better. Tier C is a fallback, not an end state.
The intent_id written into the destination’s external-reference field is what joins the destination record back to the decision, the Compliance File and the timeline. A destination without any external-reference field can still be published to, but the join then lives only on composerID’s side of the spine.

​
Two gates: vendor capability and tenant configuration

A destination that passes the tier test can still refuse a record. Tenants are routinely configured with dozens of mandatory fields, approval chains and picklists that any integration must satisfy before a record can exist. That is a configuration gate, not a connectivity gate, and composerID treats it as a first-class step.
1

Capabilities

GET /v1/destinations/{id}/capabilities reports what a connected destination supports: objects, auth, events posture and rate limits. This is the vendor gate.
2

Preflight

POST /v1/preflight validates a specific intent against the tenant’s required fields, custom fields and picklists before anything is written. This is the configuration gate, surfaced before publish rather than discovered as a failed API call.
3

Enrichment

Gaps do not dead-end. A gap returns 422 with an enrichment_request body naming the missing canonical fields, the timeline records enrichment.requested, and Triage asks the requester the missing questions where they work, so the record arrives complete instead of the tenant being redesigned around the integration.When a tenant’s mandatory-field load genuinely exceeds what intake should carry, the remaining option is a configuration change in the destination. That is an ownership and lead-time question, covered in the next section.
Publishing describes the plan, preflight and publish steps in full.

​
When the client incurs cost or configuration change

Most connections need neither budget nor a change request. The exceptions are predictable, and every one of them is visible before go-live: on the destination page, at capabilities, or at preflight.
Add two questions to your integration discovery checklist:
  1. Does your destination licence include API access, or is it a separate SKU?
  2. Who owns configuration change requests to the destination (internal admin, MSP, vendor), and what is the typical lead time?
Machine paths are upgrades applied per destination when the licence and the tenant allow, not prerequisites for going live: assisted publish reaches every destination with no vendor cost and no destination configuration.

​
Reconciliation follows the destination’s posture

Humans keep working inside the destination after publish. How composerID notices depends on what the platform offers. All four postures normalise into the same WebhookEvent envelope and the same drift flags. Events covers the envelope, the timeline and drift detection.

​
Reading a destination page

Every destination page opens the same way, and both opening blocks are derived from the registry that also drives the coverage tables and from the one carrier table the adapter reads, so the picture cannot drift from the code and stays defensible against the vendor’s own documentation. First a status line: the platform’s category, its coverage status (Specification mapped, Documented or Roadmap) and whether the vendor’s documentation is a public developer portal or gated behind a customer login. Then an Integration path table, whose four rows are: Read each row as one of two signals. Either it works from the vendor’s documented posture with no special arrangement, or you plan for it: confirm a licence, schedule polling, or budget lead time. The second is a planning signal, not a blocker. The full API posture, the field mapping and the tenant caveats follow further down each page, under API posture and Publish target and field mapping.

​
Next steps

Publishing

Plan, preflight, publish, and the idempotency rules behind every write.

Destinations

Every destination system, its posture and its coverage status.

Events

The WebhookEvent envelope, the timeline and reconciliation.