Source
Section titled “Source”One inbound stream, usually one sender. Every source owns a single ingest
URL — https://app.webhooker.eu/in/<token> — and its own verification
settings. A source can be active, paused, or in the trash.
Ingest URL
Section titled “Ingest URL”The address you paste into a provider. The token at the end is generated once and never rotates, so the whole URL is a credential.
One webhook that arrived. It records the method, every inbound header, the raw body, the verification result and the time it was received, and keeps a stable id you can quote in support tickets. Events are stored for the retention window of your plan and then removed.
Gateway
Section titled “Gateway”The route from a source to one endpoint on your side. A gateway is two objects:
- a destination — the endpoint: URL, authentication, timeout, retry schedule and any fixed headers,
- a connection — the link from one source to that destination, plus the optional filter and transformation.
The dashboard creates and edits both together. The API exposes them separately,
as /destinations and /connections, which is what lets one destination be fed
by several sources. For the wider picture of
what a webhook gateway does,
and why you would put one in front of your app at all, see the main site.
Delivery
Section titled “Delivery”One event heading for one gateway. It carries a status — pending,
delivering, succeeded, failed, exhausted or filtered — and the full
list of attempts: target URL, response status, response body, error and
latency for each try. One event with three gateways produces three independent
deliveries.
Filter
Section titled “Filter”Per gateway rules that decide whether an event is worth delivering. Rules match
on the payload (body.…) or the inbound headers (headers.…). A non-matching
event is recorded as filtered and never sent.
Transformation
Section titled “Transformation”Per gateway reshaping applied just before delivery: set, rename or remove headers, and merge extra top-level fields into a JSON body. Signing headers are added afterwards, so a transformation can never break authentication.
Signing secret
Section titled “Signing secret”Two different things share this name, so the docs always say which side:
- Inbound — the provider’s secret, used to verify what arrives. Set per source.
- Outbound — your secret, used by Webhooker to sign what it forwards, so your handler can prove the request came from us. Set per destination.
Workspace
Section titled “Workspace”The container that owns sources, gateways, events, alert channels and API keys, and the unit that plan limits and billing apply to. Everyone you invite becomes a member with a role — owner, admin or member — and every API request acts inside exactly one workspace.
API key
Section titled “API key”A token that authenticates programmatic access to the management API. Keys act with member permissions, so they can manage sources, gateways and events, but never members, roles or billing.