Your website accepts an enquiry and sends an event to a CRM integration. The first demonstration works. Production introduces retries, delayed deliveries, and events that arrive in an unexpected order.
A reliable receiver needs a processing contract, not just a public URL.
Establish what the sender guarantees
Read the sender's current documentation for signatures, delivery identifiers, timeout limits, retries, and ordering. Do not copy one provider's behavior into another integration.
Record which event types you accept and the schema version you support. Unknown event types should not trigger arbitrary business actions.
Verify before processing
Use HTTPS and the sender's documented authentication mechanism. Where signatures are used, verify the required raw request bytes before modifying or reserializing them. Apply timestamp and replay checks according to that mechanism.
A secret-looking endpoint URL is not a replacement for verification. Restrict payload size and validate the accepted schema as well.
Acknowledge durable acceptance
A useful receiver pattern is to verify the request, durably record the accepted event, and then acknowledge it. A worker performs slower CRM operations afterward.
Return the acknowledgment only after the persistence boundary succeeds. An in-memory background task can disappear if the process exits.
The exact response code must follow the sender's contract. If you cannot accept the event, return an appropriate failure instead of pretending it was safely queued.
Handle duplicate delivery atomically
Store the sender's event identifier and enforce a unique boundary. Distinguish accepted, processing, completed, and failed states so a worker crash does not leave an event permanently skipped.
A duplicated event and a duplicated business action are not always the same thing. Two different event identifiers can describe updates to the same record. Use business-level constraints where appropriate.
Plan for ordering
A delayed update should not overwrite a more recent state. If the source provides a documented sequence or version, use it. Timestamps alone may not be a reliable total order.
For some integrations, fetching the current source record before applying an update is safer than treating each delivered payload as the latest truth.
Test beyond a valid request
| Test | Expected observation |
|---|---|
| Invalid signature | Request rejected |
| Repeated delivery | No repeated business action |
| Worker crashes | Accepted event remains recoverable |
| Old update arrives late | Newer state remains protected |
| CRM temporarily unavailable | Controlled retry or review state |
Track pending age, failures, and completed processing. A fast HTTP response is only one stage of a successful integration.
Top comments (0)