Reliability and retries
How Mosce ERP retries the delivery of failed webhooks, when it disables an endpoint automatically and how to re-enable it.
Mosce ERP has an automatic retry system that guarantees that critical events reach your server even if there are network glitches or your server is temporarily unreachable. This article explains the retry schedule, when Mosce ERP disables an endpoint due to repeated failures and how to re-enable it.
Reading time: ~5 min
When to use this
- Your server was down for a few hours and you want to know if the events arrived.
- A webhook appears as "Disabled" in the settings and you do not know why.
- You want to understand how to diagnose delivery failures before contacting support.
- You need to manually resend an event that failed.
Before you start
- You need the
tenant:webhookpermission to view the delivery history and re-enable an endpoint. - See Set up a webhook if you do not yet have an endpoint registered.
Retry schedule
When a delivery fails (4xx, 5xx response, timeout or no response), Mosce ERP retries automatically up to 10 times over the following 24 hours:
| Attempt | Time since the original event |
|---|---|
| 1 (immediate) | 0 minutes |
| 2 | +5 minutes |
| 3 | +15 minutes |
| 4 | +1 hour |
| 5 | +3 hours |
| 6 | +6 hours |
| 7 | +9 hours |
| 8 | +12 hours |
| 9 | +18 hours |
| 10 | +24 hours |
If attempt 10 also fails, the delivery moves to the Exhausted state. The event is not retried anymore after this.
Retries use the same
X-Helix-Event-Idas the original attempt. Implement deduplication by this identifier in your server to process the event exactly once even if it arrives across multiple attempts. See Security and signature verification.
Delivery states
| State | Meaning |
|---|---|
| Pending | The event was created and is queued for the first attempt |
| In flight | The current attempt is being processed |
| Delivered | The server responded with a 2xx code |
| Failed | The current attempt failed; there are more pending attempts |
| Exhausted | All 10 attempts failed without success |
Auto-disable due to consecutive failures
If 3 consecutive deliveries of distinct events reach the Exhausted state (that is, all 10 attempts of each one failed), Mosce ERP automatically disables the endpoint to protect system performance.
When this happens:
- The webhook appears in the "Disabled" state in Settings → Integrations → Webhooks.
- Mosce ERP sends an email alert to the email provider configured in your integrations.
- New events are not attempted for delivery while the endpoint is disabled.
How to re-enable the endpoint
- Identify and resolve the problem on your receiving server (check the server logs, make sure the URL responds with 2xx).
- Go to Settings → Integrations → Webhooks and open the disabled webhook.
- Click Enable to reactivate it.
- Use the Test endpoint button to confirm that the connection works before waiting for a real event.
The consecutive failure counter resets to zero when the endpoint is re-enabled manually or when it delivers an event successfully.
Manual resend of a delivery
If a specific delivery failed or was exhausted and you need your system to process it, you can resend it manually:
- Go to Settings → Integrations → Webhooks and open the webhook.
- Click Delivery history.
- Find the delivery you want to resend (you can filter by state).
- Click Resend on that delivery's row.
The manual resend generates a new delivery attempt with the same payload and X-Helix-Event-Id as the original. The result of the resend appears in the history.
Delivery count and monthly quota
Your plan's monthly webhook delivery limit counts only the first attempt of each event. Automatic retries (attempts 2 through 10) and manual resends are not counted twice - only the original event counts.
See Usage limits by plan for the webhook delivery limits according to your plan.
Common errors
| Symptom | Likely cause | Solution |
|---|---|---|
| The webhook disabled without me doing anything | 3 consecutive deliveries exhausted their 10 retries | Review your server logs and re-enable the endpoint from the settings |
| I do not receive the disable alert email | The email provider is not configured | Go to Settings → Integrations → Email and configure your email provider |
| A delivery appears as "Delivered" but my server did not process it | The signature was not verified and the event was silently discarded | Check the verification logic on your server - make sure it responds 2xx only if it processes the event |
| I want to resend all the week's exhausted events | Resend is individual per delivery | Use the webhooks API to automate bulk resends if you have many pending events |
Frequently asked questions
Are the events that arrived while the webhook was disabled resent automatically when it is re-enabled?
No. Events generated while the endpoint was disabled are not queued retroactively - they are skipped. Only events generated after the re-enable are attempted for delivery. To recover skipped events, use the manual resend or query the data directly from the Mosce ERP API.
Can I configure the retry schedule?
No. The 10-attempt schedule over 24 hours is fixed for all endpoints. It is not configurable per webhook or per event type.
What counts as a "failure" for the consecutive failure counter?
A delivery is a failure when all its 10 retries finish without receiving a 2xx response. Intermittent failures that eventually resolve (for example, attempt 3 succeeds) do not count toward the disable counter.
Does Mosce ERP retry if my server responds with 429 (too many requests)?
Yes. Any response that is not 2xx (including 429) is treated as a failure and triggers the retry. If your server is rate-limiting requests, adjust the limits or consider an intermediate endpoint (internal queue) that absorbs the spikes.
Related
Last updated: 2026-05-09
Security and signature verification
How to verify that Mosce ERP webhooks are authentic using the HMAC-SHA256 signature, and how to rotate the signing secret safely.
Test a webhook
How to use Mosce ERP's test button to verify an endpoint's connectivity, interpret the result and review the delivery history.