POST (or PUT / PATCH) JSON to that URL; Planasonix authenticates the request, accepts it, and runs the pipeline.
For the full HMAC header and signing contract, see Webhook HMAC signing.
Create a webhook source URL
1
Add a Webhook Source node
On the pipeline canvas, add Webhook Source. Choose an Allowed method (
POST, PUT, or PATCH) and Authentication:- URL token only — possession of the URL is enough to fire the pipeline.
- HMAC Signature — URL plus signed headers (see Webhook HMAC signing).
2
Save the pipeline
Save or wait for auto-save. Planasonix mints an absolute ingest URL and shows it on the node as Your Webhook URL:The path token is a capability secret. Store it like an API key.
3
Send a test request
Call the URL with the allowed method and a JSON body. A successful call returns 200 and queues a pipeline run you can open in run history.
Fire the webhook
Minimal token-only example (HMAC off):X-Planasonix-Timestamp and X-Planasonix-Signature as documented in Webhook HMAC signing.
Payload
Send JSON (Content-Type: application/json). Planasonix parses the raw body into the webhook source’s output for downstream nodes. Keep payloads modest; bodies larger than 5 MB are rejected with 413. Prefer passing object storage URIs for large datasets instead of embedding file contents in the webhook body.
Column typing and confirm-before-coerce for webhook payloads are documented separately once the current canvas typing work lands. Until then, design downstream nodes against the JSON fields your sender actually posts.
Retries and idempotency
Callers often retry on timeouts. Design the pipeline so duplicate deliveries are safe (idempotent keys, upserts, or dedupe on a stable event id).Status codes
Related topics
Webhook HMAC signing
Headers, signed payload, clock window, and code samples.
Triggers
S3, GCS, Azure Blob, and file-watcher triggers.