Webhooks and headers

SimpleQ
1

I am new to webhooks and SimpleQ … but got it working :grinning:

I have setup WooCommerce to send webhooks, and it works. But how can i see if the webhook is from a creation/update/delete.

As far as I can read it is written in the header of the webhook. Can this be read with OttoFMS and SimpleQ … or do I have to create separate channels per event.

Best Lars

2

Hi Lars,

You’re correct — WooCommerce sends the event type in the request headers (X-WC-Webhook-Topic with values like order.created, order.updated, etc.).

You don’t need separate channels. OttoFMS can include the request headers in the webhook payload — just add includeHeaders as a query parameter to your webhook URL:

https://<your-server>/otto/receiver/simpleq/<your-channel>?apiKey=<your-key>&includeHeaders

That gives you a request-headers key in the payload:

{
  "request-headers": {
    "x-wc-webhook-topic": "order.created",
    "x-wc-webhook-event": "created",
    ...
  },
  "rest-of-payload": { ... }
}

Then in your OttoReceiver script you can parse out the event type and branch your logic accordingly — one channel, one script.

Full details here: Webhook Options — Request Headers

One thing to note: if you’re passing your Data API Key via the Authorization header instead of the apiKey query param, includeHeaders will expose that key in the payload. Using apiKey as a query parameter (as shown above) avoids that.

Good lucj

Todd

2 Likes
3

@toddgeist isnt that the general dilemma we have though, if someone gets into your woo control panel (or any tother service) and can find the webhook they get to see the apikey and even though it is ‘obscured’ someone could write a thing to overload the Otto service?? But most webhook providers are going for the simple one line url approach using parameters that we can then consume

4

Hey John,

Is there anything you think we should be doing differently?

Todd

5

No, not at all… it was a general point that we (might) need to be conscious about where we might be exposed, just because the real text user:pass are not present does not mean that we are ‘safe’ from misuse.

Maybe some conversations about proxies? The great thing about webhooks is that they are lightweight and we can do things as soon as one is received… but many services do not retry, so our weakest point in the chain is the uptime on our own FileMaker server. Maybe get Claris to do it of run with Connect as a relay which can also log into Studio. Or some other queue thing… then our real endpoints are not exposed…

This has changed so significantly how I think about developing almost more than anything else in the last 2 years.

6

We have built a few prototypes of an Ottomatic Service that catches all webhooks before passing them down to your server. But it would be a paid service, and we haven’t been sure we could get enough interest to make it worth while.

Maybe we were wrong, what do you think? Would there be interest in such a service?

Todd

7

Well, as ever that’s a balance. I agree it might be a smaller subset of all users.
The issue is not the catch/forward, it is in the log/fail/retry (either with backoff or manually) that the value is.

Depends on cost, but this is where I am considering needing to add to a customer experience by ensuring higher uptime. Even if it is a kind of emergency cover, like for the 60 seconds it take me to update OttoFMS
However I might build it would have a cost? with the possible exception of Connect/Studio

What if you wrote and maintained it and then we bought that, along with instructions about how to deployed in our own regions?
We get the benefit of shared cost and your high skill levels for the code

I can get 1core, 1GB for like $1.50 a month, or 2core, 2GB for $3 in the UK without going to edge/vercel etc etc