Skip to main content

Build a webhook receiver

The receiver should acknowledge a notification promptly after it has durably accepted the work. Move slower API calls and business processing to a worker.

MyCRM notification
        ↓
Validate request and subscription context
        ↓
Store notification in a durable queue
        ↓
Return HTTP 200
        ↓
Worker fetches permitted current data and applies the update

Return 200 OK after successful receipt. The reviewed sender accepts successful 2xx responses, but 200 is a straightforward acknowledgement. An in-memory queue is not durable: returning success before a notification is safely stored can lose work if the process stops.

Validate before processing​

Use HTTPS, limit body size and validate the expected payload structure, resource types and subscription context. Follow the sender-authentication arrangement agreed with LMG. The sender reviewed for this guide does not define a signature header; do not implement an assumed HMAC scheme as if MyCRM sends it.

If your worker uses resource.url, validate its origin and path against the configured MyCRM API base URL. Alternatively, construct the resource path from an allowlisted type and validated identifier. Never forward a bearer token to an arbitrary URL supplied in a request body.

Make processing repeatable​

Design updates so that receiving the same notification again does not create duplicate downstream actions. The payload does not contain a unique delivery ID, so a simple (resource.type, resource.id) key cannot distinguish every change to the same record.

For synchronisation, fetching and upserting the current record is often more robust than treating every notification as an exact state transition. Use stronger application-side controls for irreversible actions, and do not assume notification ordering.

If durable receipt fails, return a suitable failure response and recover through your operational process. Consult the status-specific retry behaviour; not every error response causes a retry.