Skip to main content
A custom webhook connection gives you a unique URL that any system can POST to. Every request that arrives fires the received event, which your workflows can trigger on. Use it for tools Shipfox doesn’t integrate with directly — CI systems, monitoring, internal services, or anything that can send an HTTP request.

​
Setup

1

Create a webhook connection

Create a webhook connection in your workspace. You choose its slug — a lowercase identifier matching ^[a-z0-9]+(?:[_-][a-z0-9]+)*$, unique within the workspace (for example deploy_hook). Shipfox returns a unique ingest URL for the connection.
2

Send events to the URL

Point any system at the ingest URL with an HTTP POST. The body can be JSON, form-encoded, or plain text. An optional X-Delivery-ID header lets you deduplicate retries; Shipfox generates one if you omit it.
curl -X POST https://<your-shipfox>/webhook/<connection-id> \
  -H "Content-Type: application/json" \
  -d '{"environment": "production", "version": "1.4.2"}'
Shipfox responds 202 Accepted with a delivery_id.
3

Trigger a workflow

Author a trigger using the connection slug as source and received as event.

​
Triggering a workflow

triggers:
  on_webhook:
    source: deploy_hook       # your webhook connection slug
    event: received
received is the only event a custom webhook emits — every request to the ingest URL fires it.

​
Event payload

Shipfox passes the request to the run as structured data:
FieldContents
methodThe HTTP method (typically POST)
headersRequest headers, with sensitive ones (authorization, bearer tokens) removed
queryParsed query-string parameters
bodyParsed JSON, or the raw body when it isn’t JSON
A filter CEL expression can reference event.headers, event.query, and event.body, but filters are parsed and not yet evaluated — every request fires the trigger today.

Triggers

The trigger schema shared by every source.

Integrations overview

Connections, slugs, and the other available integrations.