HTTP webhook

Send signed JSON payloads to any HTTPS endpoint. For custom backends, n8n, Make, Zapier, or your own infrastructure.

URL configuration

An HTTP webhook target delivers signal data as a JSON POST to any HTTPS endpoint you control. The endpoint can be anything that accepts HTTP, a serverless function, an automation platform like n8n or Make, a Zapier webhook, or your own backend.

  1. 1

    Go to Targets → New Target

    In the Signalync dashboard, open Targets in the sidebar and click New Target.
  2. 2

    Select HTTP webhook

    Choose HTTP webhook from the target type list.
  3. 3

    Enter the endpoint URL

    Paste your HTTPS endpoint URL. HTTP (non-TLS) endpoints are not accepted, Signalync requires HTTPS to protect signal data in transit.
  4. 4

    Add an HMAC secret (optional but recommended)

    Enter a secret string in the HMAC secret field. Signalync will use it to sign every request. Your endpoint can then verify the signature to confirm the payload came from Signalync and was not tampered with.
  5. 5

    Save

    Click Save. The target is now ready to add to any Route.
If your endpoint is protected by a token or API key, you can add it as a custom header value in the target settings. The header is sent with every request.

Request headers & retries

Signalync sends a standard set of headers with every HTTP webhook delivery.

Content-Typeapplication/json
X-Signalync-Signaturesha256=<hex> (only when HMAC secret is set)
X-Signalync-DeliveryUnique delivery UUID for idempotency checks

Your endpoint must respond with a 2xx status code within 10 seconds. Any non-2xx response or a timeout is treated as a failed delivery.

Retry behaviour

On failure Signalync retries up to 3 times with exponential backoff: 5 s → 25 s → 125 s. After 3 failed attempts the delivery is marked as Failed in the Signals table. You can inspect the HTTP status code and response body in the delivery detail drawer.

HMAC signing

When you set an HMAC secret on the target, Signalync computes an HMAC-SHA256 signature over the raw request body and sends it in the X-Signalync-Signature header as sha256=<hex>.

Your endpoint should verify this signature before processing the payload. Here is a Node.js example:

const crypto = require("crypto");

// rawBody must be the exact bytes received, do NOT parse as JSON first
const expected = crypto
  .createHmac("sha256", SECRET)
  .update(rawBody)
  .digest("hex");

const received = req.headers["x-signalync-signature"].replace("sha256=", "");

if (!crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(received))) {
  return res.status(401).send("invalid signature");
}

// Safe to process now
const signal = JSON.parse(rawBody);
javascript
Sign the raw request body bytes, not a re-serialised JSON object. If your framework auto-parses the body before your middleware runs, buffer the raw bytes first (e.g. in Express use express.raw({ type: 'application/json' }) ).

Payload shape

Signalync posts a JSON object containing the resolved signal fields. All fields present in the original signal are included; optional fields absent from the signal are omitted.

{
  "symbol": "EURUSD",
  "action": "buy",
  "vol": 0.1,
  "sl": 1.0780,
  "tp": 1.0950,
  "entry": null,
  "comment": "Trend follow",
  "sourceId": "src_abc123",
  "routeId": "rte_def456",
  "deliveryId": "dlv_ghi789",
  "receivedAt": "2026-04-22T14:30:25.123Z"
}
json

See the signal format reference for full field definitions, volume types, multi-TP syntax, and pending order fields.

Troubleshooting

Signature verification fails

The most common cause is signing a parsed (and re-serialised) JSON object instead of the raw body bytes. Key whitespace and key order will differ after re-serialisation, producing a different HMAC. Buffer the raw bytes before your JSON parser runs. Also confirm the secret in your endpoint matches the secret stored in the Signalync target, both are case-sensitive.

Deliveries show as failed after retries

Open the signal in the Signals table and expand the delivery detail drawer. The HTTP status code and response body returned by your endpoint are logged there. Common causes: endpoint returning 4xx (check auth headers or payload parsing), endpoint timing out (must respond within 10 s, move any slow processing to an async queue), or the URL changed after the target was created.

Endpoint timeout errors

Signalync requires your endpoint to acknowledge receipt within 10 seconds. If your processing takes longer than that, respond immediately with 200 OK and process the payload asynchronously in the background.

Duplicate deliveries

Retries can cause the same signal to be delivered more than once. Use the X-Signalync-Delivery header as an idempotency key, store the delivery ID and skip processing if you have already seen it.