Knowing a vendor’s API is not the same as knowing a customer’s system. Two companies can both use the same platform and still require completely different information before either will accept a record. This is one of the most underestimated facts in integration work.
Two gates, not one
The first gate is the vendor’s. Their documentation tells us the standard API: what a create call accepts, how callers authenticate, what comes back. That is knowable from public sources, and it is what our platform research pages summarise.
The second gate is the customer’s own configuration. A customer’s tenant, their configured copy of the platform, might add:
- mandatory fields the vendor treats as optional,
- custom fields the vendor has never heard of,
- approval rules,
- picklists with a fixed set of allowed values,
- internal classifications such as cost centres and worker types.
None of that appears in the vendor’s documentation. It is decided by an administrator, often by a managed service provider, and it changes. A message that is valid against the vendor’s published rules can still be rejected by the customer’s copy of the system, with an error written for administrators rather than requesters, after the requester has moved on.
What this means for the word “live”
A connector should not be called live simply because we understand the vendor’s API. It needs to be tested against a real or representative tenant, because the tenant is where half the rules live. That principle shapes how our own coverage table describes each platform: research against the vendor’s specification is stated as exactly that, never as a live integration.
The design we are exploring
For composer’s future adapter model, the interesting idea is to check the customer’s requirements before attempting to publish, and to turn a missing field into a question rather than a failure. If the tenant insists on a cost centre the decision does not carry yet, the better experience is to ask the requester for it, in their own words, while they are still in the conversation, instead of letting a technical error surface afterwards.
The same idea protects the customer’s governance. When an integration keeps failing on a mandatory field, the pressure lands on the administrator to make the field optional or remove an approval step so the message can land, and now the system is shaped around the integration. A mandatory cost centre is a control somebody chose. An integration should adapt to it, never the other way round.
Written with Claude. This post was drafted with Claude, Anthropic’s AI model, working from the composerID repository: the registry, the schemas, the reference sandbox and the vendor documentation it cites. Edited and published by the composerID team.