Couldn't like... X api have a cron that pings a webhook w/ a list of event_ids that haven't been 'claimed' and their timestamp of creation. The cron could easi

Couldn't like... X api have a cron that pings a webhook w/ a list of event_ids that haven't been 'claimed' and their timestamp of creation. The cron could easily maybe order the hooks by outstanding and ping those webhooks more that take longer to clear, and if there's some major bottleneck for a lengthy period...email/text the devs and let them know their access as been paused pending error review on their side. e.g. X pings Y ['events' => ['id', 'timetamp'], ['id' => '...', 'timestamp' => '...']] Y catches it, pops it onto a queue to process 1by1 or by batches. Y => pings X /fetchByIds ['id1', 'id2', 'id3'] Y => inserts data in db, pushes out any notifications, or other jobs. Y doesn't catch it. X tries again in x mins. X pings Y, but the oldest timestamp > 24 hours, it's flagged as 'dead api', triggering notifications to stakeholders to fix their shit. Saving headaches on both sides of the event/hooks. Maybe I'm missing a few steps.. but I can't fathom polling ever being a good thing, except it does kinda work better than sockets in laravel livewire, but that's because it only polls while the tab is in focus, and then only at like 10 sec increments, which is better than leaving open thousands of socket connections.... but that's a totally different use case. Mileage will vary on this, combining it with really good event sourcing and activity logging of all events should be considered to ensure data integrity - on both sides. The ability to replace events and see timelines can come in super handy when debugging.