Skip to main content
Webhooks let external systems start Planasonix pipelines with an HTTP request. Typical callers include CI/CD jobs, billing systems, internal admin tools, and SaaS workflow builders that support outbound HTTP actions.

​
Webhook endpoints

Each webhook receives a unique HTTPS URL and optional authentication requirements. When a caller posts to the URL, Planasonix validates the request, enqueues a run, and returns a correlation ID you can trace in run history.
1

Create a webhook trigger

In pipeline orchestration settings, choose Webhook, name the trigger, and select the target pipeline and branch or version if your workspace uses environments.
2

Copy the endpoint URL

Store the URL in your secret manager; treat it like a capability URL—anyone who can invoke it may incur compute cost.
3

Configure security

Enable signing (see below) and IP allowlists if your deployment supports them.
4

Test

Send a sample payload from curl or Postman and confirm a run appears with expected parameters.

​
Security (signing)

Signed webhooks include a shared secret or asymmetric key verification:
  • Planasonix adds a signature header (for example, X-Planasonix-Signature or HMAC-SHA256 per product docs) over the raw body.
  • Your caller includes the same secret to generate the signature, or you verify using a published public key.
  • Reject requests when timestamps skew beyond a short tolerance to block replayed payloads.
Rotate secrets on a calendar; update both Planasonix and the caller atomically during maintenance windows.
Never log full webhook bodies in plaintext if they contain PII or credentials. Redact before sending logs to third parties.

​
Payload parsing

Webhooks often carry JSON metadata your pipeline reads at runtime: 
{
  "event": "export.completed",
  "export_id": "exp_8f3c21",
  "location": "s3://exports-bucket/exp_8f3c21/",
  "record_count": 482910
}
Map JSON fields to pipeline parameters so SQL and source nodes reference export_id or location without hard-coding. Validate required keys early; return 400-class responses only when your webhook configuration documents strict schemas—otherwise failed runs may be clearer than rejected HTTP calls.
Prefer passing pointers (URIs) rather than embedding megabyte blobs in webhook bodies.
Callers may retry on timeouts. Make downstream processing idempotent so duplicate deliveries do not corrupt results.

Triggers

Cloud-native event alternatives.

API keys

Programmatic authentication beyond webhooks.