Which webhook did that event hit?

A customer says the payment went through and the product never heard. Tonight, three proofs, in a console you administer. Name the event: the identifier, the type, and the endpoint that received it. Show a different event that did not reach that endpoint. Show another account's destination list that does not contain this delivery. If any of the three needs the person who registered the URL, you have not shown which webhook the event hit. You have a green dashboard and a hope.

This is one delivery of one event. It is not the status stored on a subscription. Which status is that subscription in? is a field on a billing object: active, past due, and the rest of that list. A status can be active while the event never left, and an event can arrive while the status on the screen is a different word. It is not the price they were shown. Show the price they accepted is the amount on the screen and the amount that was taken. A price is not an endpoint. It is not a result that landed twice. Stop the retry that landed twice starts after a correct action happened again. A second delivery is not the same question as which endpoint the first one hit. And it is not the afternoon you move the address. Move the callback you do not hold changes where the next event goes. Moving the address does not reconstruct which endpoint this event already reached.

None of what follows is a rate for this product, and none of it is legal advice. The clocks below are one processor's current rules for delivering an event. The milliseconds below that are a 2020 thesis about one testbed. A delivery attempt is not a census of your customers. A thesis from June 2020 is not the event you opened tonight. They do tell you which numbers people mix up when they try to sound precise about a webhook they have not named.

Stripe lets you register up to 16 event destinations. 16 is a ceiling on destinations, not a count of event types, and not a count of retries. A registered webhook endpoint must be a publicly accessible HTTPS URL. The example on the setup page forwards to localhost port 4242. 4242 is an example in a command. That page does not print 4242 as a maximum, so do not promote the example into a quota. The signing secret begins with whsec_. The prefix is not a destination. Thin and snapshot are two payload formats. Thin is not snapshot. A format is not an event id (Stripe, Receive Stripe events in your webhook endpoint).

The success code and the failure codes are a second cut of that same page, and they are not the destination ceiling. The handler is told to return a successful status code, written 2xx, before any complex logic. The example they give is 200, returned before you update an invoice as paid. 200 is one member of 2xx. It is not the class. A status of 302, or any other 3xx, is a redirect, and the page says redirect responses to webhook requests are treated as failures. 302 is not 200. 3xx is not 2xx. A 400, or any other 4xx, is the destination refusing the request. The same row names 401, 403, and 405 as access restrictions, and 404 as a URL that does not exist. Those four are not one code. A 500, or any other 5xx, is the destination erroring while it processed the request. 500 is not 400. A signature that fails verification is answered with 400 in the sample. A 400 from a bad signature is not a 404 from a missing path.

Three clocks share the page and are not the same window. In live mode, Stripe attempts delivery for up to three days, with exponential backoff. Sandbox deliveries are retried three times over a few hours. Three times is not three days. A few hours is not three days. A manual resend from the Dashboard works for up to 15 days after the event was created. A resend with the CLI works for up to 30 days after creation. 15 is not 30. Three days is not 15 days. Manually resending an event that failed does not cancel the automatic retry, even if the resend returns 2xx. A 2xx you caused by hand is not the end of the schedule. The list endpoint, on a different page, only returns events created in the last 30 days. That 30 is a list window. The CLI's 30 is a resend window. Same numeral, two verbs. Do not collapse them (Stripe, Receive Stripe events and Manage webhook endpoints).

The signature is a fourth object, and it is easy to treat as the delivery. Libraries default to a tolerance of 5 minutes between the timestamp in the signature and the current time. A tolerance of 0 disables the recency check entirely. 0 is not 5. The page says not to use 0. Each send, including a retry after a non-2xx, generates a new timestamp and a new signature. The signature on the first attempt is not the signature on the second. An old signature that still verifies is a replay, which is why the tolerance exists. The API version on the event is the account's version at the moment the event occurred. The example they give is 2015-02-16. That date is an example of a version string. It is not the day the event was delivered, and changing the account's version later does not rewrite the event. 2015-02-16 is not 15 days, and it is not 16 destinations.

The study people reach for when they want a number for "webhooks are faster" is a different document, and it is not a delivery. Marcus Nilsson and Daniel Dunér, at KTH Royal Institute of Technology, dated the thesis 9 June 2020. It is a first-cycle degree project of 15 credits. The comparison is webhooks against short polling, on one machine: an Intel Core i5 3570K at 4.0 GHz and 16.0 GB of DDR3 memory, running Ubuntu 18.04.4 LTS. 16.0 GB is not Stripe's 16 destinations. 15 credits is not the 15-day resend window. 4.0 GHz is not a response time. The polling interval in their implementation is 2 seconds. They say that interval makes the polling response longer by one second on average, because the event lands halfway between polls at worst one full interval and on average half of it. One second is half of 2. It is not the 5-minute signature tolerance (Nilsson and Dunér, Scalability of push and pull based event notification).

Their acceptance line and Nielsen's line use the same 10 and are not the same sentence. They define a failed stress run as the server crashing or the response time exceeding 10 seconds. Jakob Nielsen, as they cite him, names 0.1 seconds as the limit for a response that feels instantaneous, 1 second as a noticeable delay that does not distract, and 10 seconds as the limit of the user's attention. Their 10 is a pass-fail on a test. Nielsen's 10 is a claim about attention. 0.1 is not 1, and 1 is not 10. A CPU criterion sits beside those clocks: usage should not exceed 80%, so a spike still fits. A different sentence, from a source they cite, says 100% at normal load is undesirable because throughput stops rising and response time grows. 80 is not 100. The plots for 100 and 1,000 clients draw the y-axis from 0% to 50%. 50 is an axis. It is not a measured peak, and it is not 80.

The load-test table and the method section do not print the same last row. Section 4.5.1 says the loads were 1, 10, 100, 1,000, and 10 000, increasing by a factor of 10. Table 5.1 prints average response time, in milliseconds, only through 1,000. One client: polling 1,109, webhook 83, difference factor 13.36. Ten clients: 604 and 48, factor 12.58. One hundred: 1,115 and 139, factor 8.03. One thousand: 1,916 and 922, factor 2.08. The first row is slower than the second, for both methods. They discuss that anomaly in the next chapter and do not delete it. 1,109 is not 604. 83 is not 48. There is no 10 000 row in Table 5.1. Do not invent one because the method named the load. Table 5.2 is requests, not milliseconds. One client: polling 10 requests, webhook 1, factor 10.00. Ten: 61 and 10, factor 6.10. One hundred: 777 and 100, factor 7.77. One thousand: 8,059 and 1,000, factor 8.06. The prose says webhooks sent a factor of 6 to 8 times fewer requests, except the first test. 10.00 is that exception. 6.10 is inside the range. 10.00 is not 6.10. One webhook request per client is their note. It is not Stripe's three-day retry.

The stress table is where 10 000 actually appears, and where the factor shrinks. Table 5.3, milliseconds: 10 000 clients, polling 9,212, webhook 5,750, factor 1.60. 11 000: 9,441 and 7,187, factor 1.31. 12 000: 9,099 and 6,730, factor 1.35. 13 000: 12 783 and 10 850, factor 1.18. 14 000: 11 417 and 10 520, factor 1.09. The paper prints spaces inside those thousands. Do not insert commas and call it the same cell. 9,099 at 12 000 clients is lower than 9,441 at 11 000. The table does not smooth that. 1.09 is not 1.60. 1.60 is not the load-test factor 13.36. At 15 000 clients the application crashed every time, for both methods. 15 000 is not a row in Table 5.3. It is a sentence. At 10 000 and above, the application sometimes crashed. Sometimes is not every time. Table 5.4 is requests again. Webhook requests equal the client count: 10 000, 11 000, 12 000, 13 000, 14 000. Polling requests: 77 264, 85 095, 86 262, 97 639, 98 448. Factors 7.73, 7.74, 7.19, 7.51, 7.03. They say the stress-test request factor stays around seven to eight. 7.03 is the bottom of that sentence. 4.85, which appears later, is not in this table.

The endurance table is where a printed factor does not equal the quotient of the two cells beside it. Bursts were 300, 900, and 1,800, which they say approximate 5, 15, and 30 minutes. Approximate is their word. 300 seconds is five minutes if a burst is one second, and they still wrote approximate. Do not replace the word. Table 5.5, milliseconds: 100 clients times 300 bursts, polling 1,060, webhook 35, factor 30.59. 1,000 times 300: 4,565 and 458, factor 9.97. 500 times 300: 2,054 and 220, factor 9.35. 500 times 900: 1,801 and 224, factor 8.05. 500 times 1,800: 1,259 and 235, factor 5.35. Divide 1,060 by 35 and you do not get 30.59. The table prints both. Do not replace the factor with the quotient, and do not replace the cells with a number that would make 30.59 true. Webhook times at 500 clients rise slightly as the bursts go from 300 to 1,800: 220, 224, 235. Polling times on those same rows fall: 2,054, 1,801, 1,259. A fall is not a rise. Table 5.6, requests: 238 007 against 30 000, factor 7.93. 1 455 244 against 300 000, factor 4.85. 1 036 268 against 150 000, factor 6.91. 3 227 703 against 450 000, factor 7.17. 6 875 825 against 900 000, factor 7.64. The prose says the request factor stayed between seven and eight. 4.85 is on the page. It is not between seven and eight. 30 000 is 100 times 300. It is not 30 days.

Two background sentences are easy to paste onto the event. In 2019, they write, more than half the global population used the internet, up from 16% in 2002. 16% is not 16.0 GB, and it is not 16 destinations. Data centers, as they cite Nicola Jones, consume about 1% of global electrical demand. 1% is not one client. None of these is the identifier of an event you can open.

Do the three proofs on one real event, in the console that actually holds it. First, the binding. Copy the event id, the type, and the endpoint URL that was attempted, including the HTTP status that came back. If the screen shows a type and no endpoint, write that the destination was not stored. Do not infer a delivery from a customer who got the email. Second, the other event. A different event, of a different type or aimed at a different URL, is not this one. A chart of response time is not that second event. If you cannot show an event that did not hit this endpoint, you have a counter, not a record. Third, the other account. A destination list that belongs to someone else does not contain this endpoint. If the only list is a single shared table and you cannot say whose URL it is, write that. A tenant you cannot name is the finding.

Three moves feel like the proof and are a second problem. Resending the event from the dashboard and calling the new 2xx the original delivery. The page says a manual resend does not cancel the automatic retries. It also does not rewrite the first attempt. Quoting 83 milliseconds because it is smaller than 1,109, while the event you were asked about is one row in your account. 83 is someone else's average. It is not a receipt. Asking a model which endpoint the event hit. The model will pick a plausible path. It will not open the delivery.

The path is ordinary when an operator can open one merchant's payments without opening the next merchant's. PayOrch is a payment orchestration dashboard: wallets, providers, merchants, fees, and fraud controls in one view, with a log an operator can read. The shape that matters here is one merchant you can point at, in an account you administer, distinct from the next merchant. That case is not a delivery ledger. Nothing in the description is a headcount, a duration, or a result figure. If the only control on the screen shows a day's volume and will not name an event, you do not have this proof. You have a chart.

There is a version of this afternoon where hiring the path is the wrong purchase. Nothing sends events, because the product does not talk to a processor yet. You have no product. You are still choosing who will build, and the document in front of you is a term sheet. The criteria for that choice sit on the page written for a top SaaS development company. That page is criteria. It does not rank anyone, including us. The only fact in the room is a millisecond from a thesis. 83 is not your event, and 30.59 is not your event. A customer has already seen another customer's payment. Naming an endpoint does not close a leak. Or you wanted a lawyer to say whether a notice statute applies. Hire the lawyer.

When the event is real and the console cannot name the endpoint, the missing object is specific. An admin action, in an account you administer, that shows one event id and one URL, shows a different event that did not hit that URL, and shows another account's destinations without it. A startup software development company that expects this will have put that action next to the rest of the billing screen, before a stranger's complaint is the way you discover the vendor owns the delivery. One that needs a call in order for you to see which endpoint was attempted is telling you who holds the event. If the first slice is a fixed capability, an AI integration sprint is the shape where the acceptance sentence can include the three proofs. If you do not yet know which system stores the delivery, a two-week AI readiness assessment maps the systems. The findings are yours. They are not a promise that a thesis millisecond applies, and they are not 16 destinations.

The image a deploy ran, and the tool result a model was shown, are different objects: which image did that deploy run? and which tool result did the model see?. Do not record either on this page. A digest is not an event id. A tool payload is not an endpoint.

Before you tell them the webhook fired, do the three proofs and write the URL. Name the event, or write that the endpoint was not stored. Show a different event that did not hit it. Show another account's list that does not hold it. Do not resend the event and call the new code the original, and do not ask a model which path it took. A thesis can tell you how one testbed split in 2020. The binding is the page you can defend.