Spojit Webhook Trigger

Receive HTTP requests with Spojit's built-in HMAC-SHA256 signature verification.

Overview

The Spojit Webhook Trigger is the default webhook entry point for workflows. It provisions a unique HTTPS URL per connection and verifies every incoming request with HMAC-SHA256 against a shared secret you control. Use it when you need a webhook receiver and the source system can sign requests with a Stripe-style X-Signature header.

Once a workflow's Trigger node is set to this connection, every signed POST to the provisioned URL starts a fresh execution with the request body and headers available as variables. Unsigned or wrongly-signed requests are rejected before the workflow runs, so the trigger is safe to expose publicly.

What You Can Do

This is a trigger connector - it receives requests rather than calling APIs. The capabilities are:

Provision a unique webhook URL per connection.
Generate a shared secret used for HMAC-SHA256 request signing.
Verify each incoming request's signature header (rejects on mismatch).
Expose the request body, headers, and query parameters as workflow variables on the Trigger node output.

Authentication

There is no auth into Spojit - the auth is in the other direction. The source system signs requests with the shared secret Spojit generated when you saved the connection, and Spojit verifies the signature before invoking the workflow. Treat the secret like any other API credential: store it in the source service securely and rotate it if it leaks.

Setting Up Your Connection

Go to Connections from the sidebar.
Click + Add Connection.
Search for Spojit Webhook and select it.
Spojit generates the unique webhook URL and a shared secret. Copy both.
In the source system, configure a webhook pointing at the Spojit URL. Set the signing secret to the value Spojit generated, and confirm the algorithm is HMAC-SHA256.
Name the connection descriptively (e.g. Internal Ops Webhook).
Click Save.

Using the Trigger

In the workflow designer, add a Trigger node, set its type to Webhook, and pick this connection. When the source sends a signed request, the workflow runs with these variables available:

{{ trigger.body }} - The parsed JSON body.
{{ trigger.headers }} - All request headers (including the signature header).
{{ trigger.query }} - Parsed query string parameters.

Use these in downstream Transform, Condition, and Connector nodes to act on the payload.

Tips

Test the connection by sending a curl request with a valid signature before pointing production traffic at the URL. The trigger silently drops invalid signatures.
Stamp the source's event ID into a downstream record (e.g. a tag on a Shopify order) so retries are idempotent.
If you need a different signature scheme (raw HMAC, custom header name), use the Custom Webhook Trigger connector instead.
For high-volume webhook sources, keep the workflow's synchronous path short - return early and do heavy work via a Subworkflow.

Common Pitfalls

Wrong algorithm - Some services default to SHA-1 instead of SHA-256. The trigger rejects mismatches silently; check the source service's webhook config.
Body parsing - The signature is over the raw bytes. Source services that pretty-print or re-encode the body before signing break verification.
Secret leakage - If you suspect the secret leaked, regenerate it by removing and re-adding the connection (and update the source).
Replays - HMAC verifies authenticity, not freshness. If the source sends a timestamp header, validate it in a Condition node early in the workflow to reject replays.

Common Use Cases

For technical API details and field specifications, see the Spojit Webhook Trigger trigger documentation.