Webhook Status Code Definitions

[robotdan]

Webhook Status Code Definitions

Problem

Currently a webhook treats all 2xx as a success, and anything else as a failure.

There are times where you may intentionally fail a webhook response because you want to block the request using the TX.

Solution

Support specific status codes to indicate the webhook behavior. For example :

• 2xx success / normal
• 4xx fail the request, log a debug event log if the Webhook has debug enabled, log any JSON response if available
• 5xx webhook failed, create an error event log in FusionAuth and log any JSON response if available

In the 4xx case, we could define a known response value that would allow the webhook to provide a description of cause of the failure to be shown to the end user.

This would not change the behavior of the webhooks, but it would allow FusionAuth to log the failure differently, and optionally provide different messages to the end user if this is during an interactive user workflow.

Related

• [Category] Webhooks #1543

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[ewoutquax]

A webhook can respond to a event with a message. It would be nice to show that message on the frontend.

That way, our code can inform the user what happened, eg: "invalid login-type", instead of the generic "one or more webhooks failed, please try something else."

Even better would be if the webhook can return a code in the http-body, that can be translated via defaultMessages.txt in the theme.

[mooreds]

@ewoutquax thanks for the feedback! What you wrote sounds really interesting, but would probably be better captured as a separate feature request. Would you mind filing one in this repo? https://github.com/FusionAuth/fusionauth-issues/issues/new?assignees=&labels=&template=feature_request.md is the link.

[glen-84]

@mooreds,

Do you still need a separate issue for displaying localized error messages from webhooks, or is it sufficiently covered by this issue?

{
    "error": {
        "code": "abc123", // optional code
        "message": "Show this message in the UI.", // optional non-localized message
        "messageId": "access-denied", // look up localized message, and optionally fall back to "message" (when present)
        "context": "..." // optional additional context (stack trace, etc.) to be logged
    }
}

I suppose this is also tangentially related to #1696 (the idea of returning data from webhooks).

[mooreds]

@glen-84 A separate issue is almost always a good idea. Please feel free to open one.

[andrewpai]

It would be nice to be able to respond to specific codes with certain actions, such as backing off on webhook rate when we get 429s, or retrying on certain 5** codes.