[skaiser]

In addition to what Jose posted above, we also want to encourage users to use the existing functionality as a trigger for setting up recurring handlers.

For example, if you receive an event to your webhook and you want that webhook to fire again at the same time tomorrow, make a new call to Jiter and create a new event when you receive the first event and you can chain them together. Hopefully by end of day today we'll be able to include the original scheduledTime in the webhook body so you can use that as the base for the new event (e.g., createNewEvent(body.scheduledTime + twentyFourHours)

And as Jose said, we definitely plan to make recurring events possible in the immediate future too!

Thanks for the feedback/interest!!!

[cuu508]

> For example, if you receive an event to your webhook and you want that webhook to fire again at the same time tomorrow, make a new call to Jiter and create a new event when you receive the first event and you can chain them together.

Hmm, that feels like a brittle solution. As soon as one webhook delivery fails, or the webhook receiver has a temporary problem and throws an error, the chain of callbacks is cut. And so the user has to monitor that. It also gets messy if the user needs a more complex schedule than "every x <time units>".

[skaiser]

Agreed on it being brittle. However, that's hopefully where retries come into play. And if the original request is handled but an error is thrown before the new event could be created, I'd hope there would be some form of logging in place to report that and hopefully it'd be a simple API call to restore the flow. But I definitely agree that it's messy...

All that being said, we definitely want to support true cron expressions at some point in the near future, I was mostly just throwing that out there as an option that would work today.