I think those are some excellent points, and after plenty of experience with webhook-based integrations, I agree that they are definitely a pain.
While I largely agree with you, I'm hesitant to say that it is always preferable to use an /events endpoint. There are two reasons:
1. This requires the client to essentially implement an event-sourced architecture. There are many advantages to such architectures, but they are more complicated and can be tricky to implement.
2. It's important to consider the direction of coupling in systems, and how that affects you're ability to evolve the architecture of the whole system.
3. Polling is generally going to involve a higher amount of network traffic, and will have to be weighed against the latency requirements for processing an event.
While I largely agree with you, I'm hesitant to say that it is always preferable to use an /events endpoint. There are two reasons:
1. This requires the client to essentially implement an event-sourced architecture. There are many advantages to such architectures, but they are more complicated and can be tricky to implement.
2. It's important to consider the direction of coupling in systems, and how that affects you're ability to evolve the architecture of the whole system.
3. Polling is generally going to involve a higher amount of network traffic, and will have to be weighed against the latency requirements for processing an event.