The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →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
A webhook is an HTTP request that a service sends to an address your application has registered, at the moment something happens. Instead of your application repeatedly asking whether anything has changed, the provider pushes a notification to you. That notification is a signal to act, not a complete or permanent record, and the way you handle it determines whether your integration is reliable.
This guide explains the mechanics, lays out an operating model for receiving webhooks safely, and then works through one concrete case: Plaid’s Auth webhooks that report status changes on ACH micro-deposits initiated through Plaid. The Plaid example is specific to that product and rail. It does not describe every bank transfer, payment network, bank, or webhook provider.
How a webhook works
A webhook is a provider-initiated HTTP request. Plaid describes its webhook payloads as raw JSON delivered by POST to the webhook URL the developer configured. The receiving application therefore has to do two things before any notification can arrive: expose a publicly reachable endpoint, and register that endpoint’s URL with the provider.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
A useful comparison is a delivery notification. The courier tells you a parcel has moved, but the parcel itself and its full history live with the courier. A webhook works the same way. It tells your application that something changed, and your application then decides what to fetch, store, and do. Treating the notification as the authoritative record is the most common design mistake.
#1 Best Overall
Webhooks compared with polling
The alternative to a webhook is polling: your application calls the provider’s API on a schedule and checks for changes. Each approach has trade-offs.
| Question | Webhook (push) | Polling (pull) |
|---|---|---|
| Who starts the exchange | The provider sends an HTTP POST to your endpoint | Your application sends API requests on its own schedule |
| What you must run | A reachable HTTPS endpoint that answers quickly | A scheduler and API credentials |
| Typical failure mode | Notifications lost after retries are exhausted, duplicates, or arrival out of order | Delayed detection between polls, and wasted requests when nothing has changed |
| Recovery path | Reconcile through the provider’s API or event listing where one exists | Already a read of current state, so recovery is built into the loop |
In practice, many integrations use both: webhooks for timely signals, and API reads to confirm state and repair gaps.
Setting up a webhook receiver
A receiver has five jobs. Each one is covered below in the order the request reaches your code.
Recommended Free Tools
- Expose and register an endpoint. Create an HTTP(S) route that accepts POST requests, and register its URL in the provider’s dashboard or API. Plaid requires a standard HTTP(S) URL and, when HTTPS is used, a valid SSL certificate.
- Verify the sender. Check the request using the provider’s documented verification method before trusting its contents.
- Persist the event quickly. Validate the minimum shape you need, then write the event to a durable queue or storage.
- Acknowledge promptly. Return a success status, then do slow work outside the request cycle.
- Process idempotently and reconcile. Make downstream actions safe to repeat, and fetch authoritative state when a notification is missing or ambiguous.
Verify the sender before trusting the payload
Treat every inbound request as untrusted until verification passes. Verification is provider-specific. Stripe’s webhook guidance, for example, uses a signature check computed over the raw request body with a signing secret. Do not parse the body, re-serialize it, and then verify, because whitespace and key ordering changes will break the check. Do not copy a Stripe signature recipe to another provider; use the method that provider documents.
Rank #2
- HTML CSS Design and Build Web Sites
- Comes with secure packaging
- It can be a gift option
Accept fast, persist first, process later
Keep the handler small. Plaid recommends a receiver whose only job is to write the event to a queue or reliable storage. Slow work inside the handler causes two problems: it can exceed the provider’s response window, which Plaid sets at 10 seconds, and it can overload the systems downstream. Once the event is stored, return a success response and let a worker handle the rest.
Make processing idempotent
Providers may deliver the same event more than once, and they do not guarantee arrival order. Design the action, not the delivery. Record each event identifier as processed, and check that record before creating a payment, fulfilling an order, or sending a user alert. A repeated notification should produce no second effect. Where an event’s meaning depends on a previous state, compare against the current state from the provider’s API rather than against the order in which events arrived.
Reconcile when notifications go missing
A webhook is a timely signal, not a guarantee of delivery. Plaid warns that downtime longer than the retry period can result in lost webhooks, while the underlying data remains available through its other APIs. Build a periodic job that compares your records with the provider’s current state for any object that is still pending, and that alerts you when an expected event never arrives. Where a provider offers an event listing, use it to find events you missed.
Retry behavior and the arithmetic behind it
Retry rules decide how long your endpoint can be down before events are at risk. The figures below come from Plaid’s current Webhooks documentation (accessed 2026). They are Plaid’s operating details, not a universal standard, and other providers differ.
Rank #3
- Plaid retries for up to 24 hours after a non-200 response or after no response within 10 seconds.
- The first retry delay is 30 seconds. Each later delay is four times the previous delay.
- For HTTP 429 responses, Plaid may follow the
Retry-Afterheader. - Plaid’s documented beta endpoint lists webhooks sent over the previous seven days.
Applying the stated rule to the first delay gives an illustrative schedule. These are calculated from the 30-second start and the 4x multiplier, not a log of actual Plaid retry timestamps, and Plaid’s documentation governs real timing.
| Retry attempt | Delay before this attempt | Elapsed since first failure |
|---|---|---|
| 1 | 30 seconds | 30 seconds |
| 2 | 2 minutes | 2 minutes 30 seconds |
| 3 | 8 minutes | 10 minutes 30 seconds |
| 4 | 32 minutes | 42 minutes 30 seconds |
| 5 | 2 hours 8 minutes | 2 hours 50 minutes 30 seconds |
| 6 | 8 hours 32 minutes | 11 hours 22 minutes 30 seconds |
The next calculated delay, about 34 hours, would fall outside the 24-hour window. The practical lesson is that a receiver outage of a few hours can be absorbed by retries, but an outage of a day or more should be expected to need reconciliation.
Real-world example: Plaid Auth micro-deposit events
Plaid’s Auth product includes an ACH micro-deposit flow. In that flow, Plaid initiates small deposits to a bank account so that the account owner can be verified, and Plaid’s Bank Transfers webhooks can notify your application about the status of those Plaid-initiated transfers. Plaid states that these webhooks are available to Auth customers and do not require enrollment in Plaid Transfer. Plaid also states that production approval for Auth is needed before you can add an endpoint.
What the webhook covers, and what it does not
The scope is narrow, and it matters for design:
- Covered: ACH micro-deposit events initiated through Plaid.
- Not covered: other ACH activity on a linked account, and other transfers your application initiates on its own.
- Outside this webhook’s described scope: Instant Micro-deposits, which use RTP or FedNow rather than ACH.
The notification-then-sync flow
The notification tells you that new events are available. It does not carry the full transfer record. The documented flow is:
Rank #4
- Brand: Wiley
- Set of 2 Volumes
- A handy two-book set that uniquely combines related technologies Highly visual format and accessible language makes these books highly effective learning tools Perfect for beginning web designers and front-end developers
- Register an HTTPS endpoint on the account webhooks page in the Plaid Dashboard.
- Listen for the
BANK_TRANSFERS_EVENTS_UPDATEwebhook. - When it arrives, verify and persist it as described above.
- Call
/bank_transfer/event/syncto retrieve the new ACH events, and process each one.
Reading micro-deposit event states
Each state has a different meaning, and none should be read in isolation.
| Event type | What it means in Plaid’s model | Webhook behavior | What your application should do |
|---|---|---|---|
pending |
Plaid has a record, but the micro-deposit has not been sent yet | Visible in sync responses; does not trigger a webhook | Show the transfer as in progress if you display it at all, and read it only through sync |
posted |
The terminal event type for a successful micro-deposit transfer | Delivered through the sync flow | Do not tell the user the deposit is definitely successful. Funds may appear several banking hours later, and a later reversal can occur |
reversed |
The micro-deposit attempt failed; the event includes an ACH return code | Delivered through the sync flow | Notify the user and restart the Link flow after an authentication failure, as Plaid’s documentation recommends |
The same discipline applies to other providers. Read each provider’s own state model, timing, and reversal rules. Do not carry Plaid’s ACH names or timing into a different payment provider or rail.
Security and data handling
- Keep signing secrets out of source control. Store them in your secrets manager or your deployment platform’s secret store, and limit who can read them.
- Restrict live data in test tools. Plaid says to use its Sandbox when routing webhook traffic to third-party testing tools. Live financial data should never pass through a temporary request inspector.
- Limit what you log. Log event identifiers and types, and avoid writing full payloads, account identifiers, or verification secrets to application logs.
- Reject unverified requests without processing them. Log the failure and return an error status so that verification problems are visible.
Testing and debugging
Start in the provider’s sandbox. Plaid documents sandbox endpoints that fire sample webhook events on demand, including a bank-transfer test endpoint for micro-deposit events, so you can exercise your handler without waiting for real transfers.
For a temporary listener, Plaid names Webhook.site and Request Bin as tools that provide a quick listener URL. Use them only with sandbox data. Once a listener is up, test at least these cases:
- A duplicate delivery of the same event, which should produce no second effect.
- Events delivered out of order, such as a reversal arriving before a posted event is processed.
- A non-200 response, to confirm the retry behavior you have planned for.
- A slow downstream step, to confirm the handler still acknowledges promptly.
- A request with an invalid signature, which should be rejected.
- A missed notification, to confirm your reconciliation job repairs the state.
These cases follow from the failure modes and recommendations in Plaid’s documentation; they describe the tests to write, not results from any particular run.
Comparing webhook providers
When you evaluate two providers, compare the event workflow rather than the word “webhook.” The questions below separate providers in practice.
| Axis | What to ask the provider |
|---|---|
| Authentication and verification | Which signature or verification method is used, and does its official SDK fit your stack? |
| Delivery behavior | What is the response timeout, the retry duration and schedule, the treatment of HTTP 429, and is manual replay supported? |
| Recovery | Does the API expose current state or an event history that lets you reconcile after missed notifications? |
| Event semantics | Is the notification the record itself or only a signal to fetch details? Which terminal, reversal, or correction events exist? |
| Test workflow | Are there sandbox triggers for events, and what safe tooling exists for inspecting payloads? |
| Scope and eligibility | Which product, payment rail, production approvals, and geographies apply? Confirm these directly with the provider before you design around them. |
Plaid’s bank-transfer behavior described above is specific to its Auth micro-deposit coverage, and the table is meant to make that scope visible rather than to rank providers.
Quick Recap
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.
