{
  "id": 18203801,
  "title": "Stop Trusting Notification URLs",
  "url": "https://urgent.news/2026/11/04/stop-trusting-notification-urls",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-11-04T22:11:11.000Z",
  "source": {
    "name": "HackerNoon",
    "slug": "hackernoon",
    "url": "https://hackernoon.com/stop-trusting-notification-urls?source=rss"
  },
  "original_language": "en",
  "account": "Notification URLs are sent with every bid response from a Demand-Side Platform (DSP) to track various events such as impressions, clicks, wins, and billing. These URLs can be accessed by anyone who has seen the response, leading to issues like duplicate callbacks, replayed callbacks, and callbacks for auctions the DSP did not win. This results in discrepancies in reporting and invoicing, which are the basis for discrepancy reports.\n\nThe author treated notification URLs like cheques: valid only if issued by the DSP, for that specific bid, and not previously cashed. This was achieved by minting hashes at bid time, storing them alongside the reservation, and embedding them in the notification URLs. When a callback arrives, the handler compares the hashes for that bid with the hashes in the reservation. If they match, the event is recorded, the hash is cleared, and the spend is committed. If they do not match or there is no reservation, the callback is rejected, and nothing is recorded. Reservations expire after 45 minutes if no callback arrives.\n\nThis system results in about 6% of callbacks being rejected as unverifiable, and reported impressions within 1% of the exchanges' figures. Despite the cost of writing to the shared store on every bid and reading on every callback, the author believed it was worth the expense as the alternative - reconciling discrepancies by hand every month - would be more costly and ongoing. Recent changes such as supply-path optimization, server-side rendering, and prefetching have increased the number of responses generated, making this issue more significant. The author advises DSPs to reject anything they did not issue at the point of counting, rather than relying on third-party fraud vendors.",
  "summary": "If I call your impression URL twice, what happens? If the answer is anything other than “the second call is rejected,” you are paying for the second call.",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}