Changing a field is easy. Keeping the context is the work.

First clarify which system decides

Example: a business changes the price of an accessory in the ERP. On the website, description and editorial copy sit next to it. If an older text version is republished later, it must not overwrite the current price. Sounds obvious — and still fails regularly when nobody ever recorded, field by field, who may decide.

FireFlint coordinates editorial content and publication. Line-of-business systems keep their data and price authority. Our recommendation: for every transferred field, record which system may dictate changes and which systems only adopt the value. Also decide who resolves conflicts on substance. That creates a checkable basis for development. The flows below are architecture examples for integrations to be built individually — not off-the-shelf connectors.

Revisions protect against quiet overwrites

For changes over HTTP, RFC 9110 describes a fitting mechanism: an ETag marks a specific state of a resource. With If-Match, the calling service can require that a change only runs when the tag matches. If the condition fails, the server may answer with status 412. The prerequisite is that the interface supports and correctly implements this check — “we have an API” is not enough.

Example: two people edit the same description based on revision 17. The first saves revision 18. The second save attempt with the old tag is rejected. Our recommendation: then show both versions for clarification. The tag check prevents unnoticed overwrites; which wording is right on substance is for people to decide. Technology makes conflicts visible — it does not resolve them.

Retries and order are two problems

Webhooks notify other systems about events. Delivery rules depend on the provider. Stripe documents explicitly that events can arrive more than once and that delivery does not follow a guaranteed order. As protection against double processing, Stripe recommends storing already processed event IDs. Ignore that and you eventually build silent double bookings — or at least confused teams.

Our conclusion for a custom integration: check retries and business order separately. An event ID recognises the same message again; it does not automatically reveal which data state is newer. Example: with a full state copy, a late revision 17 must not replace the already adopted revision 18. Agree a reliable revision rule with the leading system. The Stripe behaviour described is concrete evidence, not a general promise for arbitrary interfaces.

Saving and forwarding need the same starting point

Another failure mode: the application saves a change successfully but fails before sending the related message. The outbox pattern addresses that gap. It stores the change and an event entry inside the same database transaction, as one shared work step. A separate process then handles forwarding.

The open-source project Debezium documents this pattern and offers an Outbox Event Router to prepare such events. For a custom application that is one possible building block. The prerequisite is that the event entry can actually be stored with the business change. With a third-party line-of-business system you cannot simply assume that option.

Our take: first check the available extension points and operating effort. Even with an outbox, adoption in the target remains delayed; all systems therefore do not necessarily show the same state at the same time. Reliability here means: traceable and correctable — not magically synchronous.

Errors need a state someone can work

In its delivery overview Stripe distinguishes successful, pending, and failed transmissions and documents automatic retries. From that we derive a practical requirement: your integration should make clear which record is affected, which attempt failed, and who must intervene. Otherwise the error lands in a log nobody reads — and the price stays wrong until a customer complains.

Example: after a connection drop, the transfer stays visible as open. An invalid field value, by contrast, leads to business clarification. Agree limited retries, understandable error text, and a controlled restart. Also record how you recognise successful processing in the target. A mere receipt acknowledgement should only suffice if the interface contract states that explicitly.

Start with one record and clear test cases

As a first step, choose a manageable flow, for example adopting a description text into a test website. Document field authority, identifier, revision, target system, and responsible person on one page. In this example prices stay outside the write access of the editorial integration.

Then have four cases checked: a normal change, a duplicate message, a late older revision, and a failure between save and forward. Fix the expected result beforehand. Our recommendation: extend the connection only when you can reconstruct these cases and work errors deliberately. The intended benefit is less manual rework; whether it arrives you should measure in the pilot by open and corrected transfers.

Sources as of 16 September 2026. The HTTP rules refer to RFC 9110; the checked Debezium documentation refers to version 3.6. Supported features and delivery rules must be verified for the interface versions actually in use.