Best response to an HTTP webhook?

TTN V2 to V3 Upgrade V3 Integrations
1

I am writing our webhook code and am wondering at the best response from the stack’s (sender) point of view.

I figured it would not be looking at the response so a 204 no content with an empty response body would be the thing that was quickest to receive and signal the webhook is done.

I’m also assuming the stack ignores the response status so I guess this could just as well be a 200.

2

As long as you send a “success” code back, The Things Stack will be happy. Typical successful response codes we see, are:

200 OK
202 Accepted
204 No Content

2 Likes
3

Bad assumption, it doesn’t ignore the response, so you do need to send a code and can send back a 500 or other code if appropriate.

The console will show you if your web hook is returning an error or not responding fast enough (within 5 seconds).

1 Like
4

Is any other action taken by the sending server if a non-200 error code is returned, or is the only action to display it in the console?

5

Good question - there may be something in one of the other outputs - but if it’s conveyed by web hook it may not arrive. This response code checking is a new feature and I’ve not looked at that level of detail, excepting you can use the CLI to subscribe to the console stream & read that.

6

Thanks, that’s interesting it may take some action depending on the response status.

It sounds like 200 or 204 is good for my case. The plan is for my webhook to do nothing except put the message on a message queue for later processing, and perhaps write it to a local directory as a temporary cache in the case the message queue is unavailable. If both of those fail, well, I’ve done as much as I’m willing to ATM. I don’t want to also talk to the storage integration layer, and that doesn’t give any extra resiliency for non LoRaWAN sources anyway.

7

If a webhook target returns an error, The Things Stack publishes error events that you can see in the Console. If the webhook target keeps returning errors, the webhook will at some point be disabled.

It’s indeed a good plan to keep the webhook receiver as simple as possible. Just write messages to a (durable) queue and process them later in a separate process. And if you haven’t seen it already, take a look at my post Application / Integration Cookbook, that could save you some work.