Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Keep each reminder as durable application-owned work, and make every processing step safe to repeat. A webhook delivery failing is not the same as an email API send failing: the first concerns getting an event into your system; the second concerns submitting a message to an email provider. Persist intent before acknowledging inbound work, retry only errors the relevant provider says are retryable, and send exhausted or ambiguous attempts to an operator-controlled recovery path.
Why webhook and email retries need separate handling
A webhook is an inbound notification. Its sender may retry because your endpoint timed out, returned an unsuccessful response, or hit a rate limit. The same event can therefore arrive more than once; some products also deliver events out of order. An email API call is a separate outbound operation. It can be rejected or time out after the provider may or may not have accepted it.
| # | Preview | Product | Price | |
|---|---|---|---|---|
| 1 |
|
APIs and Webhooks for Beginners: Connect Apps, Automate Tasks, and Build Useful Integrations | $2.99 | Buy on Amazon |
| 2 |
|
Shelly Pro 3EM 3CT 63 Wi-Fi & LAN 3-Phase Smart Energy Meter | $150.99 | Buy on Amazon |
Neither boundary should be treated as exactly-once by default. Paxos documents at-least-once webhook delivery; Zendesk describes webhook delivery as best-effort without a guarantee, and notes that the same action can invoke a webhook multiple times. These are different provider contracts, but both demand duplicate-safe consumers. A successful email API response, meanwhile, indicates acceptance by that API, not that a message reached the recipient’s inbox.
Build durable reminder intent before doing side effects
Represent the reminder as a durable business operation, not merely as a message temporarily held by a queue. Give it a stable logical key—such as the reminder record ID plus the intended send occurrence—and persist that intent before scheduling attempts. Keep the logical key unchanged through retries and manual replay.
#1 Best Overall
A practical record can track the reminder’s logical key, intended recipient and content reference, due time, processing state, attempt history, last error class, next retry time, and any provider message or request identifier. Store only the information needed to perform and investigate the operation, with appropriate protections for personal data.
Where possible, coordinate the business-state change and creation of pending work in one database transaction. This prevents a reminder from being marked as scheduled while its queue entry is lost, or a queue entry from being created without the corresponding business change. This is a design principle rather than a vendor-prescribed schema; the exact storage model depends on the application.
Accept webhooks quickly, then process asynchronously
- Validate the request. Verify the provider’s signature and relevant request details before trusting the payload.
- Deduplicate and persist. Use the provider’s stable event identifier as a uniqueness key. Record the event durably and enqueue or otherwise create the work atomically where possible.
- Acknowledge within that provider’s deadline. Return the documented success response only after the event is safely recorded. Do not wait for slow downstream work inside the webhook request.
- Process in a worker. Claim the persisted event using a lease or visibility timeout, perform the business operation idempotently, and record the result.
Response deadlines are provider-specific. GitHub recommends responding within 10 seconds and advises asynchronous processing when work takes longer. Microsoft Graph describes a three-second initial response window; its guidance recommends persisting the notification to a queue and returning 202 when processing will exceed that window. Do not apply either provider’s deadline or response code to a different integration without checking its contract.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteIf a worker crashes after doing some work but before recording completion, the event may be processed again. The uniqueness check and the effect it protects should be coordinated transactionally where possible. If the downstream effect cannot share that transaction, make the effect itself idempotent or reconcile its outcome before repeating it.
Configure webhook retries for the actual provider
Retry rules differ by product, delivery mode, status code, and sometimes response headers. Use bounded exponential backoff with jitter where appropriate, honor instructions such as Retry-After when the provider contract says to, and distinguish temporary failures from permanent ones. Do not interpret every 4xx response as retryable: some products retry 429 while discarding other client errors.
| Provider and product | Documented behavior | Implementation implication |
|---|---|---|
| Paxos webhooks | At-least-once delivery with exponential backoff and jitter for up to 24 hours from the first invocation. The documentation lists a dashboard rate limit of 1–100 requests per second, with a default of 10 requests per second. These details are from Paxos documentation crawled 2026-10-07. | Deduplicate on the stable event identifier, acknowledge promptly, and monitor delivery. Paxos also recommends asynchronous processing and backup polling. |
| Zendesk webhooks | Best-effort delivery without a guarantee; the same action may invoke a webhook more than once. Its documentation lists up to three retries for 409, qualifying 429 or 503 responses with Retry-After under 60 seconds, and up to five retries for timeouts. Documentation crawled 2026-10-07. |
Do not assume all errors are retried or that retries follow one general schedule; make the consumer duplicate-safe and check the qualifying response conditions. |
| Twilio Event Streams | At-least-once delivery; events can arrive out of order. Its documentation describes exponential backoff with jitter and retries for up to four hours. For webhook sinks, 429 and 5xx are retried while other 400 responses are discarded. Documentation crawled 2026-10-07. | Deduplicate by event ID and avoid relying on arrival order. These rules apply to Event Streams, not automatically to other Twilio webhook products. |
| Unity Triggers | Up to three application-level retries with exponential backoff for server errors, timeouts, and rate limits, followed by a dead-letter queue. Other 4xx responses are not retried or added to the queue. Documentation last updated approximately June 2026. | Correct or suppress permanent client-side failures rather than expecting them to reappear in the DLQ. |
| Microsoft Graph notifications | The cited guidance describes retries that may continue for up to four hours and a three-second initial response window. Documentation crawled 2026-10-07. | Persist and acknowledge quickly, and plan for delayed notification processing within the documented delivery behavior. |
These examples are not a shared standard. Put provider-specific retryable codes, deadlines, headers, delivery windows, and queue behavior in configuration and runbooks. Verify the current documentation for the exact product, region, API version, and delivery mode before deployment; provider limits and policies can change.
Retry outbound email without losing the reminder
Keep the durable send intent separate from each transient send attempt. A worker should claim the intent, submit the message, and persist the outcome and provider identifiers. If the API explicitly supports an idempotency or deduplication key, use the stable logical operation key and confirm the key’s scope and retention rules in that provider’s contract.
Rank #2
- The Shelly Pro 3EM 3CT 63 is a next-gen DIN rail-mountable energy meter for single or three-phase installations, featuring a 63A, 3-phase current transformer for non-contact measurements. It supports 4-quadrant measurement, optical pulse indication of energy usage, and is photovoltaic-ready. *It doesn't have a built-in relay; contactor control requires a Shelly Pro Addon attached to the device.
- Professional Smart Meter - Shelly Pro 3EM-3CT63 is a professional smart meter that reports accumulated energy, voltage, current, active, and apparent power per phase in real time. It stores data for up to 60 days in 1-minute intervals and includes a real-time clock to maintain accurate time if the SNTP server connection is lost.
- Ideal for business energy measurement - In commercial buildings, it helps monitor energy usage across floors or departments allowing accurate cost allocation and identification of energy wastage. In manufacturing plants it tracks energy consumption of heavy machinery, optimizing usage to reduce operational costs. For store owners it monitors energy usage of systems like lighting, HVAC § refrigeration, helping to identify inefficiencies § reduce energy bills while supporting sustainable practices
- Shelly Customer Service - Shelly is one of the fastest-growing Smart Home brands in the world with devices, providing solutions for the automation of private homes, buildings and businesses. We provide our customers with professional support and a 5 years device warranty.
- Shelly Smart Control App will help you control your Shelly devices remotely and will send notifications for all automated events in your home. You can easily configure devices and manage their settings individually, or you can create personalized scenes by combining Shelly devices to trigger certain actions in your home automation.
If the provider does not guarantee idempotency for the send operation, your queue can prevent concurrent or repeated job execution, but it cannot guarantee exactly-once email delivery after an ambiguous network timeout. The provider may have accepted the message even though your application never received the response. Record the attempt as ambiguous, consult provider events or logs where available, and reconcile before replaying. Blindly resubmitting can create a duplicate email.
Classify the result before scheduling another attempt
- Rate limited or temporarily unavailable: Retry only when the API’s contract identifies the response or transport condition as transient. Honor a retry instruction where supplied; otherwise use bounded backoff with jitter and a maximum attempt count or deadline.
- Permanent rejection: Invalid recipient addresses, unverified senders, and other non-retryable rejections need correction, suppression, or another explicit business decision—not an endless retry loop.
- Unknown outcome: A timeout or broken connection after submission may leave acceptance uncertain. Preserve the intent and investigate or reconcile before resubmitting if the provider offers a way to check.
- Accepted by the API: Store the provider’s response or message identifier and handle later delivery events, bounces, and suppression according to the service contract. Acceptance is not proof of inbox delivery.
AWS SES documents that quota-exceeding API send attempts are not automatically queued for later redelivery. It reports throttling as ThrottlingException and recommends waiting an interval of up to 10 minutes before retrying; actual daily quotas and per-second sending rates are account- and region-specific. Your application must therefore retain the reminder intent and resubmit when permitted rather than assuming SES will send a rejected attempt later.
As a separate example of why limits must be read in context, Twilio SendGrid’s v3 Mail Send FAQ documents an endpoint limit of 10,000 requests per second and up to 1,000 recipients. Those are documented endpoint limits, not a recommendation or a statement of an individual sender’s available throughput or deliverability.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Control concurrency and make workers recoverable
- Claim with a lease or visibility timeout. A worker should own an item for a bounded interval. If it dies, the item becomes eligible for recovery instead of remaining stuck indefinitely.
- Prevent overlapping sends. Enforce uniqueness on the logical reminder operation and avoid letting multiple workers submit the same eligible attempt concurrently.
- Persist each outcome. Record attempt time, error class, provider response or identifier, and the next scheduled retry. Do not reset the original operation key when an attempt fails.
- Apply provider-aware rate control. Limit submission concurrency or throughput to the API’s current account-specific allowance, and react to throttling rather than increasing retries in a tight loop.
- Monitor queue health. Alert on overdue reminders, growing queue age, repeated throttling, and rising dead-letter counts—not only on worker crashes.
Buffering work through a queue can regulate send calls to an email API, but the queue does not replace application-owned state or provider-specific retry decisions. In particular, distinguish a queue’s successful handoff from an email provider’s acceptance and from final delivery.
Dead-letter and replay procedures need safeguards
A dead-letter queue (DLQ) holds work that exceeded its configured retry path or could not be processed under the product’s rules. It is a diagnosis and recovery boundary, not a promise that failed work will eventually succeed. Some systems discard exhausted messages unless a DLQ is attached; AWS SNS documents that behavior. Unity documents controls to replay or discard DLQ items.
- Inspect before replay. Review the attempt history, last error class, provider identifiers, age, and whether the destination service is healthy.
- Resolve the cause. Fix configuration, credentials, recipient data, rate control, or downstream availability as appropriate. Replaying into an unchanged failure can simply exhaust the item again.
- Reconcile ambiguous sends. For email timeouts, check available provider events or logs to determine whether the message was accepted before deciding to resubmit.
- Replay the original operation. Use a controlled action that retains the original logical reminder key and records who initiated replay and when.
- Discard deliberately when appropriate. Suppress invalid or unwanted reminders through an auditable operator decision rather than silently deleting failed work.
Expose enough history for an operator to answer what happened, when another attempt is due, and whether replay is safe. Define separate permissions or approvals for replay and discard if the impact of duplicate or missing reminders warrants them.
Quick Recap
What to verify when selecting a queue or provider
- Which status codes and transport failures are retried, and for how long?
- Can delivery be duplicated or arrive out of order, and which stable identifier supports deduplication?
- How are 429 responses and
Retry-Afterhandled, and what account-specific rate controls apply? - What acknowledgment deadline does the inbound webhook have?
- Does the queue retain exhausted messages, and can operators inspect, replay, or discard them?
- Does the email provider support idempotency for submissions, and what are the key’s scope and retention?
- Which provider events, bounce signals, suppression states, and reconciliation records are available?
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
