Skip to main content
Webhook streams turn HTTPS POST requests from vendors, internal apps, or SaaS products into a durable, ordered stream you process with the same streaming nodes you use for Kafka or Kinesis. You get a stable URL, authentication, and backpressure controls instead of operating your own ingestion tier.

Setting up webhook stream sources

1

Create the stream source

In the canvas, add a Webhook stream source (or equivalent streaming connector). Planasonix provisions a unique path and shows the full ingest URL.
2

Choose authentication

Select shared secret (HMAC), static bearer token, mTLS, or JWT validation—match what your sender supports and your security baseline requires.
3

Configure the sender

Register the URL in the vendor console or your API gateway. Start with a sandbox workspace and low rate limits.
4

Attach downstream nodes

Parse JSON, Avro, or newline-delimited payloads, then branch to quality checks and destinations.
Webhook streams are ingress-only; they do not replace orchestration webhooks that notify your systems about Planasonix events.

Payload parsing

Incoming bodies land as raw bytes plus headers. Typical patterns:
Use a JSON parser node with schema inference disabled in production; pin a JSON Schema or contract to catch vendor drift early.
Preserve vendor envelope fields (event_id, type, timestamp) as top-level metadata for deduplication and routing.
Normalize timestamps to UTC immediately after parse; vendors mix epoch seconds, millis, and RFC3339 strings in the same product line.

Authentication

Configure the signing algorithm and header names the vendor documents. Reject requests when the signature is missing or the timestamp skew exceeds your window.
Rotate tokens in two steps: add the new secret, deploy senders, then remove the old secret after traffic confirms the cutover.
Upload your client CA or use Planasonix-managed client certs. Ideal for internal services behind mutual authentication.

Backpressure policies

When downstream processing or destinations lag, the ingress layer must decide how to behave.
PolicyWhen to use
Queue and slow acceptYou can tolerate higher latency but must not drop vendor retries; watch queue depth alerts.
Reject with 429Vendor supports Retry-After; protects workers from OOM during spikes.
Sample or shedExtreme telemetry volumes where approximate analytics is acceptable—document the data loss budget.
Returning 200 before you persist creates silent loss if the process crashes. Prefer acknowledging only after durable enqueue unless the vendor contract mandates fire-and-forget.

Vendor webhook examples

Stripe

Verify Stripe-Signature with the endpoint secret; handle id per event type and use connect headers when processing Connect accounts.

GitHub

Use X-Hub-Signature-256; restrict to repository events you need; respond quickly and offload work to the stream graph.

Segment

Map track, identify, and page payloads to typed tables; watch for high cardinality properties that bloat schemas.

Custom internal APIs

Issue service tokens from your IdP; include correlation id headers for cross-service tracing into diagnostics.

Next steps

Stream processing

Windows, state, and error handling after ingest.

APIs and webhooks (connections)

Related HTTP integration patterns for batch and reverse ETL.