Webhooks

A webhook is Elistit posting to a URL you own when something finishes, so your own tools can pick up where the studio leaves off. Sending listing data to a spreadsheet, queueing social posts, filing files somewhere of your own.

You do not need one. Everything works without it. This is for people who already have a workflow to plug into.

Two kinds, and the difference matters

The account webhook fires when a pipeline completes, for every product you make, in every workspace. It works without an Etsy shop connected, which makes it the right choice if you use Elistit to generate and then handle listing elsewhere.

Per-shop webhooks fire when a listing is generated for that specific shop. Use these when different shops feed different workflows.

If you set both, both fire. They are not alternatives, so pointing both at the same Make.com scenario gets you the same event twice.

Setting one up

Integrations, then the Webhooks tab. Paste the URL your tool gives you. Make.com calls it a custom webhook; most other tools call it an inbound or incoming URL.

Each has a Test button. Use it before you rely on it. A test delivery reaches your endpoint immediately and tells you the status code that came back, which turns “did that work” into a fact rather than a guess.

Per-shop webhooks have an active switch, so you can leave a URL saved but paused rather than deleting and re-pasting it.

Checking a delivery is genuine

Anyone who learns your webhook URL can post to it. If what you do with the data matters, verify it came from us.

Set a secret alongside the URL. Every delivery is then signed: we compute an HMAC-SHA256 of the exact request body using your secret and send it as

X-Signature: sha256=<hex digest>

Your endpoint recomputes the same digest over the raw body and compares. If they differ, discard the request. The raw body matters, since re-serialising the JSON first changes the bytes and the digest will never match.

The secret is also sent as X-Listing-Secret for tools that cannot compute an HMAC. That is weaker, because it puts the secret itself on the wire, so prefer the signature where you can.

If a delivery does not arrive

Failed deliveries are retried, so a brief outage at your end usually recovers on its own.

What is not retried forever is a URL that is wrong or permanently rejecting. Use the Test button, check your endpoint is reachable from the public internet, and confirm it returns a 2xx. Tools that require authentication on inbound URLs will reject us silently unless you allow it.

FAQ

Does a webhook slow down my product? No. It fires after the work is done, and a failing webhook never fails your pipeline. Your listing and files are unaffected either way.

Can I pick which events fire? Not per event today. The account webhook fires on pipeline completion; the per-shop webhook fires on listing generation. If you need finer control, filter on the payload at your end.

Is the payload documented? It carries the generated listing content and the identifiers you need to tie it back to the project. The most reliable way to see the exact shape is to point it at a test URL and press Test, since that shows you the real thing rather than a description of it.

Can my VA set this up? Yes. Delegates can manage integrations for a shop they have access to. Billing is the only thing reserved to the account holder.

I get every event twice. You have both the account webhook and a per-shop webhook pointing at the same place. Keep one.