Where integration defects concentrate
In two places: retried requests creating duplicate records and inbound notifications not being verified. On a network timeout the client retries; if the server treats that as a new operation, a second order, invoice or payment appears. Both topics are detailed in our [idempotency and callback security guide](/en/blog/api-integration-guide).
What we do
- Integration inventory: which system is authoritative for which data, and who wins on conflict
- Operation key (idempotency) design and duplicate protection
- Webhook signature verification, time window and replay protection
- Queue-based processing, retry policy and a dead-letter queue
- Reconciliation reports and difference analysis
- A monitoring dashboard: pending queue, processing delay, failed record count
We do not treat a notification as the source of truth
An inbound webhook only says that something happened. Amount, state and outcome are re-read from the sender's API. We accept the call quickly and enqueue it, then run business logic from the queue, so the sender never times out and retries unnecessarily.
Endpoints we build most often
Bank statements and payment instructions ([bank integration](/en/products/bank-integration)), e-invoicing and e-archive, virtual POS, shipping carriers, marketplace services, accounting and ERP systems, time-attendance devices and enterprise identity providers.
"Exactly once" is a fallacy
In distributed systems you cannot guarantee exactly-once delivery. The realistic target is at-least-once delivery with a receiver that neutralises duplicates, so we also build duplicate checking by event identifier on the consumer side.
Frequently asked questions
Webhooks or polling?
At low volume and with tolerance for delay, polling is simpler and more reliable. At high volume the two are commonly combined: webhooks for fast notification and periodic polling to recover missed events.
What if our existing system has no API?
Database-level reads, file-based transfer or a purpose-built middleware service are evaluated. Whichever method is chosen, duplicate protection and reconciliation reporting are built the same way.
How do we know the integration is healthy?
Three numbers are tracked: pending queue length, mean processing delay and the count of records in the dead-letter queue. Without them on a dashboard, "it works" is an assumption.