Umovi integration platform
Delivery and retries
Webhook delivery is at least once. Consumers must be idempotent.
Retry schedule
| Attempt | Timing |
|---|---|
| 1 | Immediately after the event is queued |
| 2 | 5 minutes after the first failed attempt |
| 3 | 30 minutes after the second failed attempt |
An attempt fails after a non-2xx response, a network error or a 15-second timeout. The payload, envelope id and X-Umovi-Delivery-Id stay the same across retries. Each attempt gets a fresh X-Umovi-Timestamp and signature. A subscription has its own delivery and envelope id, so separate subscriptions receiving the same business change cannot deduplicate by a shared global event id.
Ordering
Do not assume global ordering. Separate deliveries and retries can complete in a different order than the underlying changes. Use event timestamps and fetch the current resource when ordering matters.
Suspension
Umovi increments the subscription’s failure counter for each failed attempt, including retries. A successful delivery resets it. At the configured threshold (10 by default), the subscription is disabled with reason too_many_consecutive_failures. Inactive subscriptions are skipped, including queued retries. Fix the endpoint and reactivate the subscription before testing again.
Delivery diagnostics
Use GET /webhooks/{id}/deliveries with webhooks:read to inspect recent status, attempt count, next attempt and error details. POST /webhooks/{id}/test requires webhooks:test and enqueues a real signed webhook.test delivery.
Automatic retries are available through the integration surface. Manual retry of a historical failed delivery is currently a provider workspace operation and is not part of the external Integration API.