Building and Testing Webhooks with RequestBin

I'd like to share with you all an invaluable online tool I've used over the years for Webhook integrations. It's called RequestBin.

In this article I will discuss:

• How Webhooks work (short primer)
• A typical Webhook example (using Paypal)
• Webhook Development using RequestBin

How Webhooks work

In most cases, when your application interacts with a third-party API it behaves as the client making the request and receiving responses. However, in some cases a third-party service may wish to post some data directly to your application at any time.

To facilitate this, you'll need to setup an endpoint within your application which can accept a GET/POST HTTP request. This is known as a webhook, and once it is setup you'll need to provide the full webhook url to the third-party service so they know where to send the HTTP request to.

Many third-party API services utilize Webhooks from Messaging to Payment Gateways.

A typical Webhook Scenario: Paypal IPN Webhook

I'm going to walk you through a typical webhook scenario using Paypal integration.

Imagine in your web application you have built a shopping cart which uses PayPal for processing payments. Assume you have setup a Webhook (endpoint) within your application that will accept and handle a HTTP POST request...

1. The customer creates an order and clicks on the checkout button. They are redirected to Paypal to make payment.
2. The customer authorizes the payment by clicking on the 'Pay' button on the Paypal website. Paypal does two things;
   • Generate a IPN (HTTP POST request) to your webhook with payment status information eg.('OK', 'DECLINED'),
   • Redirect the customer back to your web application.
3. When the customer is redirected back to your web application they can expect to see the result of their payment/order (Whether it was accepted).

IPN - Instant Purchase Notification

Paypal has a webhook feature called IPN; Instant Purchase Notification. Put simply, after a customer makes a payment it will generate a HTTP POST request to your web application (your webhook endpoint). The body of the HTTP POST request will contain information on the payment status of that order.

Paypal configuration setting for IPN. The 'Notification URL' refers to the webhook endpoint in your web application; the IPN HTTP POST will be sent to this url.

When your webhook receives an IPN HTTP POST request, it's up to your application/back-end on what to do next with this information. Paypal IPN only has one task; to send a HTTP POST to your webhook containing payment information. Typically, once your webhook receives the IPN request you would update the order in your database with the payment status result.

Webhook Development using RequestBin

Let's use another scenario...

Scenario: You have received a new requirement to integrate a third-party internet service eg.(Payment Gateway) into your business web application.

As you read the third-party integration guides you soon discover that you'll need to build a webhook endpoint that can accept HTTP POST requests from the third-party to your web application.

The third party has simulation tools you can use to trigger a HTTP POST request to your webhook endpoint for testing purposes.

One of the tricky aspects of building and testing webhooks is due to network connectivity eg.(Firewalls). Initially, you will build, experiment and test the webhook locally on your dev machine but that represents a problem.

How could the webhook running on your dev machine 'receive' the HTTP POST from the third-party?

...or put another way, how could the HTTP POST request from the third-party reach your dev machine over the internet?

Depending on your environment you have a few options:

1. If you're working from home you could enable port forwarding on your router to redirect HTTP/HTTPS traffic to your local dev machine.

2. If you're working in the office, your dev machine will be much more isolated from incoming connections via the internet. Also, while special traffic policies could be put in place to allow incoming traffic for local dev machine good luck getting the sysadmin to agree to that! 🤭

dev: so if you could just setup a custom traffic policy allow incoming HTTP/HTTPs connections to reach the webhook on my dev machine, that would be great! 🙂

sysadmin:

Neither option is desirable from a network security standpoint, especially long term.

If only there was a way you could create a disposable container on the internet that collects every type of HTTP request (GET/POST/PUT) sent to it. This container could have a unique url which you can then supply to third-party services for webhook development.

It would essentially be a bin of requests... 😉

RequestBin.com does exactly this!

I'll show you how to setup a bin, simulate sending HTTP requests to the bin and finally inspecting the requests.

Creating a bin

1. Go to RequestBin.com and click on the blue button 'Create Request Bin' (uncheck 'Private').
2. A disposable bin will be generated with a unique endpoint url. You'll send HTTP requests to this url and see them arrive instantly:

Sending a HTTP request

1. You can use any HTTP client such as Postman to send a HTTP request to the bin.

2. I'll be using a HTTP Request simulator provided by ReqBin.com

3. You'll need to paste the endpoint url of the bin. In my case I am posting JSON so I have set the content type to application/json and added a payload with order payment information (you can add whatever valid JSON you like).

4. When you're ready hit the send button and watch the bin very closely - you should see the request immediately appear:

There it is... pretty neat! - With this approach, there are no messy firewall issues to contend with, it just works. You can drill down to greater details of every HTTP request such as headers.

There is no substitute for testing a webhook against your actual web application, but using RequestBin can make the development much easier. You could copy the requests you receive in the bin into the Postman app and then initiate a HTTP request to the webhook hosted on your local machine for a close test.

Finally, there are some other tangible benefits using these types of bins:

• Investigation, R&D - Integrating third-party services takes an enormous amount of time and resources. Because of this developers and stakeholders will be keen to test/play with sandbox integrations before fully committing to doing the work. Bins like RequestBin.com enable one to quickly interact with third-party webhooks without having to write any code or setup/configure networking infrastructure.

• Troubleshooting - With any type of third-party integration they'll always be some technical hiccups randomly occurring. With RequestBin you have another webhook endpoint completely unrelated to your servers and their network. This can be very useful for debugging issues. For example, suppose you have discovered that there have been no requests coming into your webhooks on the production server for the last several days. Who's to blame - the production server or the third party?... A request bin will reveal!

I'll leave you with a list of recommended request bins, best of luck with your webhook integrations 👍

Bins/Tools

• https://requestbin.com/
• https://requestbin.net/
• https://reqbin.com/ (Used for generating HTTP requests)