Webhooks Integration

How Native Webhooks Work

Native webhooks are a direct, one-way notification feed: the moment a record changes in Standard Time®, the server sends an HTTPS POST straight to a URL you provide — no middleman platform in between. This is intentionally simpler than the Zapier integration: webhooks only push notifications out of Standard Time®. If you need Standard Time® to create or update records in response to something happening elsewhere, use Zapier instead.

Every subscription you register is scoped to one event type — for example project.created — and one target URL. You can register as many subscriptions as you need, mixing event types and destinations freely.

Supported Event Types

All 11 record types available elsewhere in the Standard Time® API — the same set exposed through OData and Zapier — are available here, each with three events: created, updated, and deleted. That's 33 event types in total. The deleted event is unique to native webhooks — Zapier has no equivalent, since a deleted record can't be queried for field data.

A deleted payload is intentionally minimal, since the record no longer exists to query:

{ "event": "project.deleted", "id": "41984ad9-9efd-4af2-9212-037a49a736fc" }

created and updated payloads carry the full field set for that record type — the same column names used by the OData feed (e.g. ProjectID, ProjectName, ClientID for projects).

Security: HMAC Signing

When a subscription has a secret, Standard Time® signs the request body with HMAC-SHA256 and adds it as a header, using the same convention popularized by GitHub and Stripe:

X-ST-Webhook-Signature: sha256=<lowercase hex digest>

Verification is the same pattern in any language — recompute the HMAC over the exact raw request body using your secret, then compare to the header value:

// Node.js
const crypto = require('crypto');
const expected = 'sha256=' + crypto.createHmac('sha256', secret)
    .update(rawBody, 'utf8')
    .digest('hex');
if (!crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(receivedHeader))) {
    // reject — signature mismatch
}

# PowerShell
$key  = [System.Text.Encoding]::UTF8.GetBytes($secret)
$msg  = [System.Text.Encoding]::UTF8.GetBytes($rawBody)
$hmac = New-Object System.Security.Cryptography.HMACSHA256 @(,$key)
$hash = $hmac.ComputeHash($msg)
$expected = "sha256=" + (($hash | ForEach-Object { $_.ToString("x2") }) -join "")

Create a Webhook Subscription

1. Open the Tools ribbon → Integration dropdown → Webhooks API.
   In the top ribbon, click the Tools tab. In the Integration panel, click the Integration dropdown and choose Webhooks API.
2. Fill in the event type, target URL, and secret.
   Choose an event type (e.g. project.created) from the dropdown, paste your endpoint's URL into Target URL, and leave Auto-generate checked for the secret unless you already have one in mind. Click Add Subscription.
3. Copy the secret immediately — it is shown only once.
   A panel appears with your HMAC secret. Copy it into your endpoint's configuration now; Standard Time® never displays it again. The subscriptions list shows *** in place of the secret from then on.
4. Use the Test button any time to fire a sample payload.
   Each row in the list has a Test button that POSTs a representative sample record to your endpoint immediately, without waiting for a real record change — useful for confirming your endpoint is reachable and your signature verification code is correct. Delete removes a subscription; the Active column shows whether it's currently live.

Smoke-Test with webhook.site

webhook.site is a free tool that hands you a unique URL and logs every incoming request — headers and body — with no signup or local setup. It's the fastest way to confirm a subscription is working before pointing it at a real endpoint.

1. Open webhook.site and copy "Your unique URL."
   Go to webhook.site in a new tab. Copy the URL shown under Your unique URL — it looks like https://webhook.site/d3cb1088-6609-....
2. Register a project.created subscription pointing at that URL.
   Back in Standard Time®'s Webhook Subscriptions dialog, select event type project.created, paste the webhook.site URL, keep Auto-generate checked, and click Add Subscription. Copy the secret when it appears.
3. Save a new project in Standard Time®.
   Any name works. Switch back to the webhook.site tab within a few seconds — a new entry should appear in the left-hand request list.
4. Inspect the request.
   Click the new entry. The right-hand pane shows the request headers — including x-st-webhook-signature — and the raw JSON body, which should contain an "event" field matching your subscription. The example below shows what a delivered project.updated event looks like on webhook.site.
5. Click Test in the Standard Time® dialog to fire a sample payload.
   A second request should appear on webhook.site immediately, using sample data rather than a real record.
6. Delete the project, then confirm the deleted payload.
   A third request should arrive with a minimal body: { "event": "project.deleted", "id": "..." }.
7. Delete the subscription and confirm the feed stops.
   Remove the subscription from the dialog, save another project, and confirm no further requests reach webhook.site. This confirms the subscription — not something else — was the source of the traffic.

Connecting to Popular Apps

Most enterprise automation platforms can catch an arbitrary JSON webhook and route it into their own workflows — posting to a chat channel, creating a ticket, or updating a spreadsheet. Each one gives you a URL to paste into the Target URL field in Standard Time®. Because our payload is plain JSON with no fixed schema requirements on the receiving end, any generic "catch webhook" trigger works.

Beyond Native Webhooks

Native webhooks are the right tool for a fast, one-way event feed into infrastructure you already control. Two other Standard Time® integrations cover different needs: