Strip away the vocabulary and an integration is two computer systems exchanging something they both understand, on purpose, in a way both sides agreed in advance. Everything else is detail.
The detail matters because every system has different rules, and all of them have to be satisfied at once. There are three things every integration has to get right.
1. Can I connect?
The receiving system needs proof that the caller is allowed in. In practice that is a credential: a username and password, an API key, or a token issued after a short handshake. It is the equivalent of a badge at reception. Engineers call this authentication.
2. What information does the other system expect?
The two sides have to agree on the shape of the data: the field names, whether each field is a date or a number or text, which fields are required, how long a value can be. Get any of it wrong and the receiving system rejects the whole message, usually with a terse error written for its own administrators. This is what people mean when they say “the data format” or “the schema”.
3. Where do I send it?
The receiving system publishes addresses to call: one for creating a record, another for reading it back. The set of addresses and rules is the system’s API, its application programming interface. The API also sets the manners: how many results come back at once, how often you may call, what happens when a connection drops halfway.
Every integration document you have ever seen is one of these three things, dressed up in a different vendor’s vocabulary. There is no fourth thing.
Why the same idea keeps being built again
Because every system has its own version of the three. In Beeline’s published specification, the field that carries an external reference is called externalId. Fieldglass and Coupa each have an equivalent with a different name and different rules. The idea is identical in all three; the work that satisfies each one has to be done separately.
And even then, two companies using the same platform can require different information, because each company configures its own copy. That problem is large enough to deserve its own article.
Where composerID fits
composerID takes the Triage decision reference and publishes it using the rules of the destination system: the destination’s own way of proving the caller, the destination’s own shape for the message, the destination’s own address. The rules differ from system to system. The reference is the same everywhere.
That is the whole idea. The more technical articles on this blog are about doing that one job carefully.
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.