Skip to main content
Before you start: identify the durable source, destination API and its acceptance semantics. Choose a compatible local peer path only if the workflow needs a collector. This guide defines an integration contract, not a ready-made adapter. Use this pattern for readings, inspections and local workflow results that must reach an existing system of record.
A direct source-to-backend upload can remain in place. Add a local collector where it solves a coverage, access or cost problem; it is not a requirement for every deployment.

​
Define the delivery contract

Do not clear the source merely because sendMessage returned or the SDK reported delivery. Decide whether collector acceptance transfers responsibility or whether the source retains the record until upstream acceptance.

​
Build the adapter

Map your event into the destination’s schema. Use stable IDs, idempotency keys or duplicate-safe writes. Record the difference between request acceptance, asynchronous processing and the final business result. Reject invalid records explicitly and preserve enough information to diagnose them. Keep credentials at the destination adapter. Use bounded storage and retention, classify transient and permanent failures, and expose pending count, oldest-event age and rejected records to operators.

​
Recover after interruption

Test lost connectivity, process restart, repeated delivery, expired credentials, destination rejection and full storage. Compare source event IDs with independently read destination records. Measure missing and duplicate business records separately from duplicate network transmissions. The SDK supplies the local communication layer. The source outbox, collector transaction and destination commit policy are integration responsibilities. Confluent and other integrations reuse this contract.

​
Completion check

Done when: independently queried destination records account for the source event IDs after outage, restart and duplicate submission. Continue with production qualification.