How composerID connects
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. composerID is built for that reality — five connection methods, one publishing contract, and the Intent ID on every path.
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 transport is an implementation choice, not a different product.
Ordered by how much of the loop composerID runs for you. A deployment can mix methods per destination — the Channel Map records which method each destination uses.
1 · Direct API (adapter publish)
The default. composerID's adapter authenticates to the destination's own API, maps the canonical intent through the tenant's MappingProfile and writes the record idempotently. Best fidelity: native objects, native validation, external IDs returned on the receipt.
Watch for: on some enterprise platforms API access is licensed separately — the scorecard's “Confirm licence” signal. See costs & configuration.
2 · Signed webhooks (we push to you)
composerID emits HMAC‑SHA256‑signed events (intent.published, enrichment_request, drift flags) to endpoints you register — middleware, an iPaaS trigger, or a reporting suite. Your side decides what happens next.
Watch for: webhooks reach systems you control. Most destination platforms expose no general inbound webhook endpoint for record creation — the write into the destination still happens via method 1, 3 or 4.
3 · composerID API (you pull from us)
Your integration team calls our REST API (api.composer.id/v1) to read intents, receipts and timelines, then handles the last mile in code you own. The right shape when an internal platform team already runs destination integrations.
Watch for: reconciliation becomes your responsibility — poll the timeline or subscribe to webhooks (method 2) so drift is caught.
4 · Client iPaaS & third‑party connectors
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.
Watch for: recipe volume consumes the client's iPaaS subscription; connector coverage and field depth vary by platform and tier. Procurement orchestration platforms (Zip, ORO Labs) can also carry the publish as part of an orchestrated flow.
5 · Assisted publish (deep link + prefill)
The universal fallback: composerID renders a one‑click deep link into the destination with the Intent ID and the decided values; a human completes the record in the vendor UI. No destination configuration and no vendor licence cost, available from the start of a deployment — and the record is still anchored to the audit spine.
Watch for: the external ID is captured on confirmation rather than returned on an API receipt, so reconciliation is manual or poll‑based.
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. Method 1 where the licence allows it; 4 where an iPaaS already owns that system; 5 wherever a machine path isn't viable yet.
Each platform page's scorecard shows the posture we can defend from that vendor's documentation.
| Method | Transport | Destination prerequisites | Where cost can arise |
|---|---|---|---|
| 1 · Direct API | composerID adapter → destination API | API access enabled; integration user / OAuth client | API access licensed separately on some platforms |
| 2 · Signed webhooks | composerID → endpoints you register | None (your endpoint, not the destination's) | Internal build/hosting of the receiver |
| 3 · composerID API | Your code → api.composer.id | None | Internal integration engineering |
| 4 · iPaaS / connectors | composerID → iPaaS recipe → certified connector | Connector configured against the tenant | iPaaS subscription / task volume; premium connector tiers |
| 5 · Assisted publish | Deep link + prefill into the vendor UI | None | None (human completes the record) |
There is a minimum contract for a destination to sit on the automated path — and a defined fallback when it can't. The target for any destination-of-record is Tier B or better; Tier C is a fallback, not an end state.
| Tier | The destination provides | What composerID runs | Reconciliation |
|---|---|---|---|
| Tier A | An inbound create/update API; an external‑reference field that carries a 10–64‑character ID (the intent_id); events or a queryable change feed back out. | The full loop: plan → preflight → publish → back‑sync. | Automatic — events normalised into the WebhookEvent envelope. |
| Tier B | An inbound create/update API and an external‑reference field, but no usable events out. | Publish as Tier A; reconciliation switches to scheduled polling on the destination's change timestamps. | Poll‑based; drift flagged against the canonical intent. |
| Tier C | No usable inbound path — no API in the licence, an unpurchased API SKU, or tenant configuration that blocks machine creation. | Assisted publish (deep link + prefill), a client iPaaS connector, or the managed‑programme (MSP) path. | External ID captured on confirmation; manual or poll‑based. |
Why the external‑reference field matters — the join keyExpand
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.
A destination passing the tier test can still refuse a record: tenants are routinely configured with dozens of mandatory fields, approval chains and picklists that any integration — ours or anyone's — 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.
Capabilities
GET /capabilities reports what a connected destination supports: objects, auth, events posture, rate limits — the vendor gate.
Preflight
POST /preflight validates a specific intent against the tenant's required fields, custom fields and picklists before anything is written — the configuration gate, surfaced before publish, not discovered as a failed API call.
Enrichment
Gaps don't dead‑end. Preflight emits an enrichment_request back to intake, 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 — which is an ownership and lead‑time question. See costs & configuration.
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 platform scorecard, at capabilities, or at preflight. Nothing here should first appear as a surprise in week six.
| Scenario | What changes, and who acts | Cost signal | Typical lead time |
|---|---|---|---|
| Assisted publish only | Nothing in the destination; the deep link opens the vendor UI as the requester's own user. | None | Immediate |
| Receive our webhooks / pull our API | Client team stands up a receiver or scripts against api.composer.id; the destination is untouched. | Internal engineering time only | Days |
| Standard API connection | Destination admin creates an integration user or OAuth client, allow‑lists composerID and enables event subscriptions. | Usually included in the existing licence | Days |
| API access is a separate SKU | The vendor enables an API / integration module on the client's contract before any adapter can connect. | Vendor licence cost — confirm with the account team | Weeks (commercial, not technical) |
| Publishing via the client's iPaaS | A recipe is built on the client's existing integration platform; the connector writes to the destination. | Consumes existing iPaaS subscription (task / recipe volume) | Days to weeks |
| Tenant configuration change | Mandatory fields, approval chains or picklists are changed by the internal admin, the MSP or a vendor change request. | Change‑request cost varies — often MSP‑managed | Weeks (governed change control) |
Ask these two questions early
Add them to your integration discovery checklist
Why costs stay rare
Assisted publish gives every destination a no‑cost, no‑configuration path from the start of a deployment. Machine paths are upgrades applied per destination when the licence and the tenant allow — not prerequisites for going live.
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.
| Posture | Meaning | Reconciliation |
|---|---|---|
| Push events | The platform delivers native webhooks or events on record change. | Event‑driven back‑sync. |
| Push + poll | Events exist but are partial or per‑tenant; polling fills the gaps. | Events where enabled; scheduled poll fallback. |
| Poll‑first | No general event bus; records are re‑read on change timestamps. | Scheduled polling against the canonical intent. |
| No native events | Neither events nor a change feed; relaying requires platform scripting. | Poll, or a relay built in the platform's own tooling. |
Every platform page opens with a four‑cell scorecard derived from the registry — the same source that drives the coverage tables — so the picture stays defensible against each vendor's own documentation.
The four cells
Publish path — how composerID writes (Direct API via the adapter).
Events back — the platform's reconciliation posture, as above.
API access — open developer docs, or customer‑gated with a possible separate SKU.
Contract tier — where the platform sits against the destination standard.
The two colours
Green works from the vendor's documented posture, no special arrangement.
Amber plan for it: confirm a licence, schedule polling, or budget lead time. Amber is a planning signal, not a blocker.
The adapter pattern, the endpoints and every platform's individual posture.