Getting Started with Hookbako

Even if this is the first time you have heard the word "webhook," this page will show you what Hookbako can do and how to use it. It is free, requires no registration, and takes about 3 minutes to try.

What is Hookbako?

First, what is a webhook?

Many services have a feature that notifies your server when something happens. This is a webhook.

Notifying your program when someone sends a message to a LINE Official Account
Notifying an inventory management system when a product sells in an online shop
Posting a chat notification when someone opens a pull request on GitHub

The service sends data (an HTTP request) to a URL you have registered beforehand. Think of it as a letter from the service: you give the service a destination URL and say, "Please send it to this address."

The problem: you cannot see what arrived

When building a program that receives webhooks, many people run into these problems.

You do not know whether anything is actually arriving
The documentation alone does not clearly show what the incoming letter's contents look like
You cannot test it because you have not built the receiving program yet

Hookbako is a box for receiving test requests and looking inside

Hookbako is a temporary mailbox for webhooks. With one button, you get your own receiving URL. Register it as the destination in a service, and the incoming letters (requests) appear on screen, ready to open and read.

You do not need to set up a server or write a program. You can first find out what arrives and what it looks like, then build your production program.

Try generating a receiving URL →

When it comes in handy

Starting to build a LINE bot: See what the data looks like when messages or stickers are sent.
Integrating payments (such as Stripe): Check the contents of payment-completed notifications and whether they come from a test environment.
Connecting no-code tools or business systems: Send actual requests to check whether kintone or another webhook-capable tool is configured correctly.
Testing requests from your own program: Check whether your scripts or IoT devices are sending data correctly.
Tracking down why requests are not arriving: If they arrive at Hookbako but not at your own server, you know the problem is on your server's side.

Try it in 3 minutes

Without registering for a service, you can send a test from your own computer and watch it arrive.

On the home page, click "Generate a receiving URL." The inbox opens, with a receiving URL such as https://hookbako.fourgetkun.com/en/h/… at the top.
Bookmark the inbox page URL (the URL in the address bar). It contains the key you need to return to this page later.
Try sending data to the receiving URL using one of the methods below (replace YOUR_RECEIVING_URL with your own URL).

Mac and Linux (Terminal)

curl -X POST 'YOUR_RECEIVING_URL/hello' \
  -H 'Content-Type: application/json' \
  -d '{"message":"hello"}'

A test command is already shown on the inbox page, so the easiest option is to copy and paste it.

Windows（PowerShell）

Invoke-RestMethod -Method Post -Uri 'YOUR_RECEIVING_URL/hello' -ContentType 'application/json' -Body '{"message":"hello"}'

When sending Japanese text from older versions of Windows PowerShell, characters may turn into "?". We recommend starting with letters and numbers.

Try it using only your browser

With the Hookbako inbox page open, open your browser's developer tools (F12), paste the following into the Console, and press Enter.

fetch('YOUR_RECEIVING_URL/hello', { method: 'POST', body: JSON.stringify({ message: 'hello' }) })

If you do the same on another site's page, that site's restrictions may prevent sending or cause red CORS errors in the console. To send from another site, open "Configure response" in the inbox menu and turn on "Allow browser requests (CORS)."

After sending, one new request appears immediately on the left side of the inbox page.

Understanding the interface

Hookbako inbox interface: received requests on the left, with body, signature verification, headers, and replay cards on the right — Inbox interface (examples received from LINE, GitHub, and a form)

Inbox (left): Received requests appear newest first. When the provider is recognized, such as LINE or Stripe, its name and what happened are shown.
Heading (top right): A summary of the selected request, including the time received, sender's IP address, and size.
About this request: Explains what the event is and what to do next. You can also add notes.
Body: The contents of the received data. Use "Formatted" for easier reading or "TypeScript" to display generated type definitions.
Signature verification: Checks whether the request really came from the provider (see the signature verification guide).
Headers and query: Additional information that came with the data, including the provider's name and signatures.
Replay locally: A command for sending the same request to a program running on your own computer.

Useful tips

Use different paths to distinguish providers

You can append any path to the receiving URL. Register separate paths such as …/h/YOUR_ID/line and …/h/YOUR_ID/stripe to see at a glance where requests came from, even when testing multiple services in one inbox.

Filter with search

Use the search box at the top to filter with expressions such as provider:line (only requests from LINE), method:POST, or path:/stripe. Plain text searches also look inside the body.

Change the response to test the provider's behavior

Use "Configure response" in the inbox menu to change the reply sent to the provider. For example, returning 500 (an error) makes services with retry mechanisms, such as Stripe, treat the delivery as failed and resend it after a delay. This is useful for testing retries.

Generate types from received data

Click "TypeScript" in the body section to generate TypeScript type definitions from the received JSON. You can paste them directly into your production program when you start writing it.

Send the same data to your own program

In "Replay locally," set the destination to a program running on your computer (for example, http://localhost:3000) and run the displayed curl command to test its behavior with the same data as a real request.

Use keyboard shortcuts

Press j for the next request and k for the previous one. Press / to move to the search box.

Organize with names and notes

You can name your inbox (for example, "LINE bot development"). Leave notes on requests you want to revisit to make them easier to review later.

Things to keep in mind

Do not share the inbox page URL. It contains a key, and anyone who knows it can see the contents.
Do not send passwords or personal information. Hookbako is a testing tool. Do not send real customer data or similar information.
Deleted after 7 days. An inbox and all its contents are automatically deleted 7 days after creation. To keep anything, save it using "Export all" in the menu.
Only the latest 100 requests are stored. Older requests are deleted in order. Each inbox can receive up to 1,000 requests in total.

Mini glossary

Webhook: A mechanism through which a service sends data to a specified URL to notify you when something happens.
Endpoint: The URL to which data is sent. Hookbako's "receiving URL" is an endpoint.
Request: A single delivery of data. Each row in Hookbako's list is one request.
Headers: Additional information sent with a request, describing things such as which service it came from and the format of the data.
Body: The actual contents of a request. It is often written in a format called JSON.
JSON: A data format that uses field-and-value pairs, such as {"name":"Yamada"}.
Status code: A number returned by the receiving side. 200 means "received," and 500 means "an error occurred."
Signature and secret: A mechanism for checking that a request came from the genuine service, and the shared secret used for that check. Only a sender that knows the secret can generate the correct signature.