Webhooks

With Webhooks, it’s easy to create notifications out of ScopeStack into other tools via Power Automate or Zapier.

In your professional Zapier account, select the Webhooks by Zapier application. In the trigger setup, select Catch Hook as the Trigger Event and press Continue.

Next, Zapier will provide you a Custom Webhook URL . It typically begins with https://hooks.zapier.com/hooks/catch/ …

Copy that value out of Zapier.

Create the Webhook in ScopeStack

In ScopeStack, navigate to Settings > Account > Webhooks.

Here, you can see any existing webhooks in your account or create new ones. Click the + Add A Webhook Subscription button to create a new webhook.

On this screen: The Webhooks page shows a table with columns for Event and Webhook URL, listing any existing webhook subscriptions. A + Add A Webhook Subscription button is in the page header, and selecting rows reveals a bulk Delete.

Select the Event you want to trigger the webhook from the list of events. Then, provide the Webhook URL that the hook will be broadcast to — the URL you copied out of Zapier.

On this screen: The new webhook form has two fields: an Event dropdown to select the trigger event, and a Webhook URL text field to enter the destination URL. A note below the URL field states that the endpoint must accept a Content-Type of application/vnd.api+json. Click Submit to save.

The following event types are available:

Click Submit when complete.

In your ScopeStack account, perform an action to trigger the webhook. Webhooks are delivered typically within minutes; the exact timing is infrastructure-dependent.

Deliveries are processed in batches from a single queue shared by every ScopeStack account, in the order the events were recorded, rather than being sent the instant the event happens. That is why delivery latency varies, and why two events recorded close together arrive in the order they occurred.

Webhook subscriptions can also be created and managed programmatically via the API at /v2/webhook-subscriptions.

Once you can successfully test the webhook catch, you can finish setting up your Zap. You can use the information in the webhook to complete many other operations.

Permissions

The Webhooks (settings.webhooks) permission under Settings > Roles controls access:

• View: See existing webhook subscriptions in Settings > Account > Webhooks.
• Manage: Create, edit, and delete webhook subscriptions.

Checking delivery history

If a webhook stops arriving, or arrives late, you can read the delivery history for a subscription.

Open the subscription from Settings > Account > Webhooks and select the Publications tab. It lists every delivery attempt with columns for Status, HTTP Status, Source and Created At, and a View button on each row that opens the content that was sent.

The same history is available over the API:

Each record reports the delivery status, the HTTP status returned by your endpoint, the source that triggered it, the contents that were sent, and timestamps. That is usually enough to tell a rejected delivery (your endpoint returned a 4xx or 5xx) from one that was never triggered.

These endpoints are read-only.

A failed delivery is never retried

Delivery is attempted once. If your endpoint returns anything other than a success status, ScopeStack records the attempt with the status your endpoint returned and moves on. It is not re-sent, and there is no way to re-send it from the app.

So an endpoint that was briefly down, misconfigured, or answering 404 loses those events permanently, and nothing in ScopeStack tells you it is happening. If you depend on webhooks, read the delivery history above on a schedule rather than waiting to notice missing data.

The same event can arrive more than once

One document generation records several status transitions, and document_status_changed fires on each of them. Identical payloads are suppressed before anything is sent, so in practice a fast generation produces a single delivery. A slow one does not: if the document is still generating when the first event fires, you can receive an in-progress delivery and then a second one when it finishes.

Treat deliveries as idempotent, and filter on the status you care about rather than assuming exactly one delivery per generation.

One related case that surprises integrators: re-requesting a document that has already been generated, without forcing regeneration, reuses the existing record, changes no status, and therefore fires no event at all.