FWIW my engineering org built a service that pretty much does what Jiter offers because we need to do things like schedule messages to be sent in the future. >

FWIW my engineering org built a service that pretty much does what Jiter offers because we need to do things like schedule messages to be sent in the future. > And for execution in environments like GitHub Actions or AWS Lambda, they all have functionality to trigger execution with a timer. We use it for triggering things dynamically within services. For example, when someone books a flight we need to send a follow-up email X amount of time later. Building a scheduler into the service that handles booking the flight might make sense, but what happens when we need to do the same thing for someone booking a hotel or car rental? Instead we just have a service that stores all of the messages it needs to send in the future and has a tight reconciliation loop to send out those webhooks. > This introduces added complexity of maintaining a webhook receiver and having to deal with the rather complex failure modes of webhooks. If you only need to do it once, sure. If you standardize the behavior/API then it reduces complexity a ton.