What does a Webhooker ingest URL look like?

It is the app host plus /in/ and the source's token, for example https://app.webhooker.eu/in/6b225n04u5kmyg. The token is 14 lowercase letters and digits, generated once when the source is created and never rotated, so the whole URL should be treated as a credential.

Which HTTP methods and payloads does the ingest URL accept?

POST, PUT, PATCH and DELETE, with any content type and a body up to 1 MiB. JSON is parsed so filters can address it; anything else is stored and forwarded byte for byte. Every inbound header is kept, and the query string is accepted and ignored.

Why does ingest answer 200 instead of 202?

The response is sent once the event is durably stored, not once it has been delivered. Delivery runs out of band on its own retry schedule, so a slow endpoint on your side never slows the provider down and never triggers the provider's own retries.

What happens when a webhook fails verification?

The request is answered 401 and the event is still stored, marked failed, with no deliveries created. Nothing reaches your app, but the attempt and all its headers stay visible in the event log, which is how you tell a wrong secret from a wrong URL.

The ingest URL

Every source has one ingest URL. Anything that can make an HTTP request can use it — no SDK, no handshake, no account on the sender’s side.

https://app.webhooker.eu/in/6b225n04u5kmyg

Ingest URLs listed on the Sources page — Each source owns one ingest URL, shown in full on the Sources page.

Request format

Property	Accepted
Methods	`POST`, `PUT`, `PATCH`, `DELETE`
Body	Anything, up to 1 MiB. JSON is parsed for filters; other payloads are stored and forwarded byte for byte.
Headers	All of them are stored and available to filters and transformations.
Content type	Any. Recorded as sent.
Query string	Accepted and ignored.

There is nothing to sign and no envelope to build: send the provider’s payload exactly as it comes.

curl -X POST https://app.webhooker.eu/in/6b225n04u5kmyg \
  -H "Content-Type: application/json" \
  -d '{"type":"invoice.paid","amount":4200}'

GET requests

A GET never returns event data. It serves a plain information page, so a teammate who opens the URL in a browser sees an explanation rather than an error.

One exception: Meta platforms (Facebook, WhatsApp, Instagram) confirm an endpoint with GET …?hub.mode=subscribe&hub.challenge=…. Webhooker echoes hub.challenge back as text/plain, which is what those platforms expect, so the subscription check passes with no configuration.

Response codes

Code	Meaning	Stored?
`200`	Accepted and stored. Delivery starts out of band.	Yes
`401`	Inbound verification failed.	Yes, as `failed`, with no deliveries
`402`	The workspace used up its monthly event quota.	No
`404`	No such token, or the source is in the trash.	No
`413`	The payload is over 1 MiB.	No
`429`	The source is over its per-minute ingest budget. `Retry-After` says when to come back.	No
`500`	Webhooker could not store the event. Safe to retry.	No

The success body is JSON:

{
  "status": "SUCCESS",
  "message": "Request received successfully.",
  "request_id": "0190a0b1-c2d3-7e4f-8a9b-0c1d2e3f4a5b"
}

request_id is the event id. Quote it when you need to trace one webhook end to end.

Providers that require a different status or body can be served one — see custom responses.

Why 200 and not 202

The answer is sent once the event is durably stored, not once it is delivered. Delivery happens out of band, with its own retry schedule, so a slow endpoint on your side never slows down the provider and never causes the provider’s own retries. An accepted event is not lost if your endpoint is down — it waits in the delivery queue.

Paused sources

A paused source still answers 200 and still stores every event; deliveries are suppressed until you resume it. The provider sees healthy responses throughout, and you replay the backlog when your handler is ready.

Size and rate limits

Payloads are capped at 1 MiB. Per-minute ingest budgets are per source and depend on your plan — see limits.