Queue Webhook Events with IronMQ Webhook Support

You can now use IronMQ as a webhook endpoint to collect webhook events/messages from third parties. This new feature supports arbitrary HTTP POSTs to an IronMQ queue and it will store the body of the POST in your queue.

Now why would you want to do this? There’s plenty of good reasons, here are a few:

  • Ensure reliable delivery – if you need to ensure that you get each and every webhook message, you can use IronMQ to ensure that no message gets lost and you can guarantee that the message gets processed before it gets removed from the queue.
  • Collect webhook events and deal with them later such as in a nightly batch run.
  • Use multiple queues to collect messages for different processes/systems.
  • Don’t worry about your service getting bombarded with webhook requests that it has to deal with synchronously, your workers can grab stuff off the queue when they’re ready and available.

Let’s Try It!

To use IronMQ webhooks, you just need to get your webhook URL for your queue.

https://mq-aws-us-east-1.iron.io/1/projects/MY_PROJECT_ID/queues/MY QUEUE NAME/messages/webhook?oauth=MY_TOKEN

Replace MY_PROJECT_ID and MY_TOKEN with a project id and token from HUD. Replace MY_QUEUE_NAME with whatever you want to name the queue.

Let’s quickly post something to our webhook endpoint with curl:

curl -d 'I love queues'  

Replace MY_PROJECT_ID and MY_TOKEN with your project id and token then run that command. Go ahead, give it a try.

Now let’s grab that message off the queue:


(notice I removed “webhook” from the URL, otherwise it’s the exact same as above).

You should get a response like this:

{"messages":[{"id":"5828196657047927116","body":"I love queues","timeout":60,}]}

Now if we want to acknowledge that we’ve handled the message, we need to delete it (if we don’t delete it, it will go back on the queue after a timeout, this ensures messages have been processed). Copy the message id you got in the response above and use it in a curl delete:

curl -X DELETE 

Now that we’ve tried posting an arbitrary http post to our queue, let’s try it from a real service.

Example: Posting GitHub Service Hooks to IronMQ

Let’s try a real world example using GitHub service hooks. All we need to do is add the queue’s webhook URL to the Webhook URLs section of GitHub service hooks. Go to your GitHub repository, click “Settings”, then click “Service Hooks”. Change the QUEUE_NAME in your queue URL to github-webhook-queue to keep it separate from our tests above, so the new URL would be:


Paste that URL into the GitHub interface:

Click “Update Settings” then test it by clicking “Test Hook”. Since there’s not much of a response in the GitHub interface when you do this, you can check to see that you got a message by looking at your queues list in HUD.  If it says 1, then it’s all good so let’s grab the message from the queue using curl.

curl https://mq-aws-us-east-1.iron.io/1/projects/MY_PROJECT_ID/queues/github-webhook-queue/messages?oauth=MY_TOKEN

The response you get will look pretty ugly because unfortunately GitHub posts a big chunk of json as an HTTP form parameter called “payload” so we have to decode it first. Here’s a Ruby example to decode and get the proper values:

For more information on what’s contained in the GitHub payload, check here.



There are a bunch of reasons to put a message queue between your systems and this feature enables you to use a queue between your systems and a third party. The only thing the third party needs to do is support webhooks which is becoming more and more common. Sign up for IronMQ now to try it out.

Webhooks are the events, message queues are the glue.

  • Is it possible to have a restricted use OAUTH token that can only be used to insert into a queue?

  • Hi Paul, not currently, but we will be coming out with more find grained authentication in the near future.

  • Is there any way to access the HTTP headers that were included in the POST? For instance Shopify includes information in the headers with their webhooks (http://wiki.shopify.com/WebHook#Headers) – might be handy to get at that data in a lot of cases.

  • Hi Matt, not currently, we only capture the body right now. Capturing headers is probably a good idea though, I’ve added it to our list to review. Thanks!

  • Excellent – that would be the only thing blocking me from using it today, personally, as that Shopify example is a real use case for me – I need the headers they send to process their webhooks correctly – I’d love more than anything to ditch the current solution for handling this in favor of IronMQ – if the receiver is down and the webhook fails they don’t give you much help when tracking down the problem.