The webhook protocol currently treats only HTTP 200 (http.StatusOK) as a successful response. Any other status code (including other 2xx codes such as 202) is treated as an error.
Please add support for an allowlist of accepted status codes (e.g. 200, 202) so webhook integrations can treat other 2xx codes as success.
Some webhook endpoints legitimately respond with status codes other than 200 (for example 202 Accepted when the payload is queued for async processing). Today these are handled as failures even though the request succeeded from the sender’s perspective.
For instance, this would be helpful a Zipkin-related input package being added in elastic/integrations:
And zipkin receiver returns a 202 code when sending JSONs to its endpoint (related code).
Could it be added a new configuration option to define which HTTP status codes should be considered successful for webhook delivery (as allowed list)? The default value for this allowed list should be 200 to keep the same behavior as it is now.
The webhook protocol currently treats only HTTP 200 (http.StatusOK) as a successful response. Any other status code (including other 2xx codes such as
202) is treated as an error.Please add support for an allowlist of accepted status codes (e.g.
200,202) so webhook integrations can treat other 2xx codes as success.Some webhook endpoints legitimately respond with status codes other than 200 (for example 202 Accepted when the payload is queued for async processing). Today these are handled as failures even though the request succeeded from the sender’s perspective.
For instance, this would be helpful a Zipkin-related input package being added in elastic/integrations:
And zipkin receiver returns a 202 code when sending JSONs to its endpoint (related code).
Could it be added a new configuration option to define which HTTP status codes should be considered successful for webhook delivery (as allowed list)? The default value for this allowed list should be 200 to keep the same behavior as it is now.