thanks, both are useful.

1. we support OAuth apps today, and we're growing the catalog based on demand. we support rotating and refreshing tokens for those.

2. I'd like to understand your case better. sitting in the request path means we could own retry mechanisms, but I'm curious what made you think of it, what kind of use cases did you have in mind?

Almost every API caller has to add the logic for retries based on the response codes, centralizing it with the gateway optimizes the repetitive code across the clients.

Trip breaker patterns are good for resource usage on both sides (client and server) when you know things are not working. In addition to that it also saves on cost for the clients if every call is billed irrespective of success or failure.