2xx response acknowledges a webhook delivery. For a batch, it acknowledges the entire { items } body; do not return success after persisting only some of its items. A non-2xx response or transport failure does not acknowledge the delivery, and delivery is at least once, so your receiver can see duplicates in any order.
Receive a webhook safely
Keep the HTTP handler small. Do not run slow business logic, enrichment, or downstream API calls before acknowledging the request.- Read
X-Immoteur-Event-Idand use it to persist or durably enqueue the event idempotently before acknowledging it. - Return
204 No Contentor another2xxresponse as soon as that work is safe. - Process the event in your own worker or queue after the HTTP response. The queue and worker are your integration architecture, not an Immoteur service.
classified-notification-batch payload, use X-Immoteur-Event-Id as the batch idempotency key. Persist or durably enqueue the complete batch before acknowledging it, then upsert each Classified by its identifier without relying on item or arrival order.
Timeouts
Immoteur currently applies a 5 seconds connection timeout and a 5 seconds request timeout. A receiver that waits for slow work can time out before it acknowledges the delivery. Persist or enqueue first, then return a successful response quickly.Read the delivery headers
Do not promise redelivery, exactly-once delivery, arrival order, or global ordering. A batch keeps the same request body and event ID across retries, while
X-Immoteur-Delivery-Id changes for each HTTP attempt.
Export chunks do not promise event-ID stability, so process an export according to its exportId, exportType, item identifiers, and completion signal. exportType has the same effective value on every data batch and terminal completion message; it distinguishes a Full export (full) from a Delta export (delta) without exposing the requested mode or fallback reason.
Retries and circuit breaking
A non-
2xx response, including a 4xx, is not a successful acknowledgement. classified-notification-single and classified-notification-batch deliveries use the same HTTP pool, headers, timeouts, retries, circuit breaker, proxy routing, and delivery statistics. An export can have multiple delivery attempts and chunks; do not assume a fixed chunk size or strict order.
Immoteur applies the appropriate retry policy after an unacknowledged delivery. When 1,000 retry events are in flight for one service, its circuit opens at the next level of the cooldown ladder: 10, 20, 60, and 360 minutes. Each later actual opening advances to the next level, while openings after the final level remain at that level.
Customer email notifications are sent only when an opening advances to one of those levels, not for later openings that remain at the final level. An opening does not deactivate the service.
The cooldown sequence resets only if no new circuit opening occurs during the 30 minutes after the circuit closes; a new opening during this grace period continues the sequence. No successful 2xx delivery is required, so silence counts toward the grace period. Deliveries for that service are skipped during the cooldown and are not automatically replayed, so retain enough state to deduplicate retries and use a later export to reconcile data after a circuit outage.
Configure the endpoint and filters in Configure Immoteur webhooks. Use Mirror classified data for the full export, live notification, and delta-export integration flow. Use API reliability for API rate-limit headers.