Why an integration shouldn’t automatically own your content

A connector gets built because two systems hold related records. It gets dangerous when nobody writes down which system is allowed to change which field.

This applies to CMS integrations, product feeds, CRMs, marketplaces, PIM systems, syndication tools, and marketing platforms. The pattern is the same everywhere: a system is connected, it starts writing, and nobody agreed in advance what it was allowed to overwrite.

1. Separate four kinds of authority

“Source of truth” is usually used as though a system either is one or isn’t. That framing is too coarse to build against. It is more useful to split it.

System of record is where an entity officially lives for legal, financial, or operational purposes. It is often not the system users look at.

Source of truth for a specific domain is narrower and more useful. One system can be authoritative for pricing while another is authoritative for description and imagery, for the same product.

Creation authority is the right to bring a record into existence. This is frequently the safest thing to delegate to an external system, because creating something that did not exist destroys nothing.

Update authority is the right to change a record that already exists. It is where the real risk sits, and it should be granted field by field rather than entity by entity.

2. A worked example

An animal rescue lists adoptable dogs on its own website and on an external listing service. Both systems hold a record per dog. The obvious integration keeps them in step.

The obvious integration is also the wrong one. The rescue writes careful descriptions and takes its own photographs. The listing service holds a thinner version of the same dog. Sync everything, and the thinner version wins on every run.

What was actually built splits the authority:

• The website owns description, status, and media. The feed may not overwrite any of them.
• The feed holds creation authority. A newly listed animal can be introduced by the feed, seeded once, and then owned by the website from that point on.
• The feed holds exactly one piece of update authority: it may move a currently adoptable or on-trial animal to Adopted.
• That single update fires only when the animal disappears from the feed and the disappearance is reconfirmed against a second endpoint.
• A failed or empty response aborts the run before anything is marked.

Notice how narrow the write permission is. One field, one direction, one trigger, confirmed twice. Everything else is read-only toward the website.

That example is written up as Content Ownership Across Integrated Platforms, one strand of a wider rescue operations engagement.

3. An empty response is not automatically valid business data

This is the part most integrations get wrong, and the failure is quiet.

An API returns an empty collection. Nothing errored. The status code is fine. The integration reads that emptiness as a fact about the world and acts on it.

In the rescue example, an empty feed means one of two things: every animal has genuinely been adopted, or something upstream broke. Those are indistinguishable from the response alone, and only one of them should cause writes.

So the rule is to treat absence as unproven rather than as a signal. If a run returns nothing, or returns fewer records than a plausible floor, stop and report rather than proceeding. Deletion and state-change signals in particular deserve confirmation from a second call, because they are the ones that destroy information.

4. Why “sync everything both ways” is a poor default

Bidirectional sync sounds like the complete version of the feature. It is usually the version nobody can reason about.

Two systems that can both write the same field need a conflict rule, and “last write wins” is a rule only in the sense that a coin toss is a decision. It resolves by timing rather than by correctness, so the record that survives is the one that happened to be saved second.

It also makes every failure ambiguous. When a field holds the wrong value, you can no longer tell whether someone edited it, the connector wrote it, or the connector overwrote a human edit. Logs become the only way to reconstruct intent, and by then the original value is gone.

One-directional authority per field is easier to build and much easier to debug. Where a field genuinely needs to move in both directions, that is a specific decision with a specific conflict rule, not a default setting.

5. Decide this per field, before building

For each entity, and then for each field that matters, answer these before the connector is written:

• Who creates it?
• Who is allowed to update it?
• Which system wins in a conflict, and on what basis other than timing?
• What does an empty response mean here?
• What should happen when the integration is unavailable?
• Is deletion authoritative, or does it only mean “no longer listed”?
• Can the change be reversed, and by whom?
• What is logged, and would it be enough to reconstruct what happened?

Most of these take a minute to answer while designing and are expensive to answer after a bad run. The output is small: a short table of fields and who owns them, kept next to the connector code.

The test of whether the exercise worked is simple. If a connector does something surprising six months later, someone should be able to open that table and see whether the behavior was intended.