Sources

A source represents a service that sends HTTP requests to Hookdeck. In the Console, creating one gives you a URL you can hand to a provider straight away, with no account.

Creating a source

Open console.hookdeck.com/new and one is created and opened for you.

You can create as many sources as you need, and switch between them from the source picker in the top navigation. A source per provider you're testing is a common way to work, so a Stripe payload and a Shopify payload don't land in the same list.

Sources can also be created with the Console API, with no account and no API key, which is how you'd spin one up inside an integration test:

curl -sS -X POST "https://console.hookdeck.com/"

The response carries the new source's ingest and inspect URLs. See the Console API reference.

Ingest and inspect URLs

Each source has two addresses, and they do different jobs:

• The ingest URL (console.hookdeck.com/e/<id>) is where requests arrive. This is the one you give to the service sending them.
• The inspect URL (console.hookdeck.com/<id>) is where you read them. This is the page you keep open.

A Console source costs nothing to create and needs no setup, so its ingest URL is most often used as a test URL, a stand-in endpoint you point a provider at while you work out what it sends.

Setting a Source Type

A source is a generic WEBHOOK source unless you give it a Source Type naming a platform, such as STRIPE or SHOPIFY. Set it when you create the source, either from the source picker or with the type field in the Console API.

A Source Type doesn't restrict what the source accepts. A source typed STRIPE still captures a request from anywhere, including one you send by hand. In the Console it does two things:

• Preselects that platform's payloads in the Webhooks Library.
• Handles the challenge handshake for the few platforms that require one before they'll start sending, so those providers accept the URL.

It does not verify signatures. Verification needs the platform's signing secret, and the Console has nowhere to put one. If you want requests verified before they're accepted, configure authentication on a source in an Event Gateway project.

Source Types that can't work without configuration aren't available in the Console. Asking for one returns an error rather than creating a source you couldn't use.

Supported HTTP methods

Console sources accept GET, POST, PUT, PATCH, and DELETE. Requests using any other method are rejected.

That matters because not every provider sends POST. A source captures a GET webhook the same as any other request.

GET and DELETE carry no request body. They're still captured, along with their method, headers, path, and query string.

Renaming and deleting sources

Rename a source from the settings menu beside it in the source picker. Deleting one removes the source and every request captured against it, and can't be undone.

Who can access a source

Console sources are not private. Knowing a source's ID is the only thing that grants access to it. Anyone with the ID can send requests to it, read every request it has captured along with the responses, and open it in the Console.

That's deliberate, and it's what makes a source shareable: send the link to a colleague and you can both watch the same requests arrive, with nothing to configure.

It also means the ID is a capability rather than a secret. Treat a Console source as public. Don't send it anything you wouldn't want anyone holding the link to read, and don't point production traffic at one.

If you want private sources, use an Event Gateway project. You get everything described here and more, except that nothing is visible until you add team members to the project yourself.

This applies only to sources you create in the Console. It never exposes anything else in your Hookdeck account.

Source retention and Hookdeck accounts

Without an account, the Console remembers your sources in the browser you created them in, for up to 90 days.

Choosing Save Data creates a free Hookdeck account. The sources you've already made carry over as they are, along with the requests they've captured, and become available across sessions and devices.

Event list limit

The events list shows the most recent 250 requests for a source.