Nimriz
SaaS & developers

Link automation and webhooks for clicks

Click events and link lifecycle changes should not be trapped in a dashboard. Nimriz emits signed webhooks for every short-link click, QR scan, and lifecycle mutation so your downstream tools can react in near real time instead of waiting for a manual export.

  • Receive signed click and QR-scan events via webhooks, Zapier, Make, n8n, or a Generic HTTP destination
  • Subscribe to the full v1 event catalog including link.created, link.updated, and link.clicked
  • Rely on six-attempt retry logic, dead-letter replay, and test-send to keep automation healthy
Start for freeAll use cases
Workflow trigger map

One click event fans out into alerts, syncs, reports, and custom HTTP actions.

Event-driven
Trigger
event = link.qr_scanned
Slack alert
Triggered from the same canonical click event with destination-specific mapping.
CRM update
Triggered from the same canonical click event with destination-specific mapping.
Sheet append
Triggered from the same canonical click event with destination-specific mapping.
Webhook sink
Triggered from the same canonical click event with destination-specific mapping.

Most short-link platforms stop at the dashboard. Clicks accumulate, but triggering a Slack alert, updating a CRM record, or appending a row to a Google Sheet requires a manual export, a scheduled batch job, or a third-party polling hack. That lag compounds during live events and trade shows, exactly when real-time signal matters most.

Nimriz solves this with a signed webhook layer built on top of its short-link event model. The v1 event catalog covers six types: link.created, link.updated, link.takedown_updated, domain.verification_updated, link.clicked, and link.qr_scanned. Click and QR-scan events exclude bot traffic, so only genuine human interactions reach your downstream systems. Each delivery is signed with HMAC-SHA256 and sent asynchronously so the redirect path is never blocked.

For teams that prefer no-code tools, Nimriz connects to Zapier, Make, and n8n via scoped installation tokens. Recipes such as posting a Slack alert on every QR scan, logging click metadata to a Google Sheet, or updating a CRM contact are built inside those platforms using Nimriz as the trigger source. When a workflow needs more control, a Generic HTTP destination can POST events with custom headers and payload templates to any HTTPS endpoint.

Delivery reliability is handled by at-least-once semantics with up to six retry attempts, exponential backoff, and dead-letter state with operator replay. A test-send feature confirms your endpoint and signature verification are working before a campaign launches. The result is a workflow layer that connects branded link activity directly to the tools your team already uses, without manual intervention.

Who it is for

Marketing ops and automation builders

Connect short-link and QR-scan events to Zapier or Make workflows that post Slack alerts, append to Google Sheets, or update HubSpot records without writing server code.

RevOps and backend engineers

Subscribe a signed webhook endpoint to link.clicked and link.qr_scanned events, verify HMAC-SHA256 signatures, and pipe the structured payload into CRM pipelines, data warehouses, or internal event buses.

Growth and lifecycle marketers

React to link lifecycle events such as link.created and link.updated to keep campaign inventories, tagging systems, and downstream reporting in sync without manual reconciliation.

What you get

Click-event webhooks

Subscribe an HTTPS endpoint to the link.clicked and link.qr_scanned event types and receive a signed payload the moment a real human clicks or scans. Bot traffic is excluded automatically, so your downstream workflows only process genuine engagement. On supported plans, the same endpoint can also receive link lifecycle events such as link.created and link.updated in the same subscription.

Zapier, Make, and n8n

Connect Nimriz to Zapier, Make, or n8n using scoped installation tokens so no-code and low-code builders can react to click and lifecycle events without writing a custom receiver. Use the automation platform to route the event into Slack, Google Sheets, a CRM, or any tool already in your stack. For cases where those platforms do not have a matching connector, a Generic HTTP destination covers the gap.

Generic HTTP destination

POST events to any HTTPS endpoint with custom headers and an optional payload template. This destination type covers internal microservices, queue consumers, incident-management tools, and any receiver that accepts a JSON POST but does not have a named connector in Nimriz. Because delivery is async and queue-backed, your redirect path is never affected by the downstream receiver.

Reliable delivery with retries and replay

Nimriz delivers at-least-once and retries up to six times with exponential backoff starting at 60 seconds and capped at 900 seconds. If all attempts fail, the delivery moves to dead-letter state where you can inspect the error and manually replay when your receiver is healthy again. A test-send feature lets you push a synthetic event to any endpoint before a campaign goes live, confirming your signature verification and downstream routing without waiting for a real click.

How it works

Turn clicks into downstream actions

Nimriz publishes link lifecycle and click-driven signals into an async delivery layer that feeds webhooks, no-code platforms, and custom HTTP endpoints. The same canonical event stays consistent regardless of how many destinations consume it.

1
Plan

Subscribe a webhook endpoint or connect Zapier, Make, or n8n to the event types your workflow needs.

2
Publish

Verify the HMAC-SHA256 signature on each delivery using the raw request body bytes and your endpoint signing secret.

3
Measure

Build the downstream recipe: post a Slack message, append a sheet row, update a CRM contact, or fire an internal service handler.

  • Use at-least-once delivery and dedupe on the stable Nimriz event id to handle retries without duplicate side effects.
  • Watch success rate, retry attempts, and dead-letter items from the integrations dashboard. Replay failed deliveries when your receiver is healthy.
  • Test-send a synthetic nim.webhook.test event to any endpoint before a campaign goes live to confirm routing and signature verification.
Explore automation and APITrust and privacyFAQ
Example
Trade-show QR scan
1. Visitor scans booth QR code
2. Nimriz emits link.qr_scanned (bot traffic excluded)
3. Zapier recipe: post Slack alert + append to Google Sheet
4. Generic HTTP destination sends the same event to CRM pipeline
Result
One scan updates the team channel, the reporting log, and the CRM without any manual follow-up. The same event id lets each receiver dedupe safely on retry.

Setup

  1. 1
    Subscribe an endpoint or connect a no-code platform
    Go to Settings → Integrations → Webhooks to add an HTTPS endpoint and choose the event types you want. For Zapier, Make, or n8n, create a connection using a scoped installation token from the same integrations area. Subscription filtering is by event type; select link.clicked and link.qr_scanned for click-driven workflows, or add lifecycle event types for operational alerts. Click-event webhooks are available on supported plans (Professional and above).
  2. 2
    Store the signing secret and verify each delivery
    Nimriz generates a unique signing secret for each endpoint. Copy and store it securely as a server environment variable. On every delivery, verify the X-Nim-Signature: v1=<hex hmac sha256> header by computing HMAC-SHA256(secret, "{X-Nim-Timestamp}.{rawBody}") against the exact raw request body bytes before parsing JSON. Reject any request that does not pass. See the webhook docs for a complete Node.js verification example.
  3. 3
    Build your recipe: Slack alert, sheet log, or CRM sync
    In Zapier or Make, map the incoming event fields to your downstream action. The payload includes stable ids (link_id, domain_id), safe destination fields (destination_host, destination_url_capped), geo and device context, and UTM parameters. Raw long URLs and secrets are never included. For a custom backend, parse the verified JSON and trigger your internal handler. Dedupe on the stable id field to handle at-least-once retries safely.
  4. 4
    Validate with test-send before launch
    Open the endpoint in Settings → Integrations → Webhooks and click Send test event. A synthetic nim.webhook.test event is delivered with X-Nim-Delivery-Reason: test so you can confirm reachability, signature verification, and downstream routing without waiting for a real click. Check delivery history to see response codes and any errors.
  5. 5
    Rely on retries and replay for operational continuity
    If your endpoint returns a retryable response (HTTP 408, 409, 425, 429, or 5xx), Nimriz retries up to six times. Backoff starts at 60 seconds and doubles each attempt, capped at 900 seconds. Exhausted deliveries move to dead-letter state. Find failed events in the delivery history, fix the underlying issue, and click Replay to re-deliver the original event envelope with the same id and payload. Your deduplication logic treats a replay as an intentional duplicate.

What good looks like

Without click-event webhooks

  • Click and QR-scan data sits in the Nimriz dashboard and requires a manual export to reach other tools
  • No real-time trigger means Slack alerts and CRM updates happen hours or days after the event
  • Batch jobs and polling introduce lag and create fragile scheduled dependencies
  • Link lifecycle changes such as destination updates are invisible to downstream systems without manual reconciliation
  • No signed delivery means downstream tools cannot verify that events are authentic

With Nimriz link automation and webhooks

  • Signed link.clicked and link.qr_scanned events fire the moment a real human interacts, with bot traffic excluded
  • Zapier or Make recipes post Slack alerts, append Google Sheet rows, and update CRM records automatically
  • Generic HTTP destinations reach internal services and custom backends with full payload control
  • Lifecycle events (link.created, link.updated, link.takedown_updated) keep operational systems in sync
  • Six-attempt retry logic, dead-letter state, and manual replay keep automation reliable across receiver outages

Outcome: link and QR events drive automated workflows in near real time without manual exports, polling, or fragile batch schedules.

Frequently asked questions

What event types fire in the v1 webhook catalog?

The v1 event catalog includes six event types:

  • link.created — a new short link was created
  • link.updated — a non-takedown mutation such as a destination change, slug change, or expiration change
  • link.takedown_updated — a moderation or safety workflow changed link availability
  • domain.verification_updated — a domain verification or readiness state changed
  • link.clicked — a short link was clicked, excluding bot traffic
  • link.qr_scanned — a QR code was scanned, excluding bot traffic

Endpoints are workspace-scoped and subscription filtering is by event type. Per-link or per-domain filtering is not part of the v1 webhook subscription model.

What does a click or QR-scan event payload contain?

Every webhook delivery uses a consistent envelope with a stable id, type, api_version, created_at, organization_id, workspace_id, and a data object. The data object for click and scan events includes stable ids (link_id, domain_id), short_url, domain_name, short_code, touch_type, country, device_category, browser_family, os_family, referrer_host, social_source, and UTM parameters where present.

Raw long URLs are intentionally excluded to avoid leaking query-sensitive or signed destination parameters. API keys, signing secrets, and other credentials are never included in any webhook payload. Destination context is exposed as the safe fields destination_host and destination_url_capped on lifecycle events.

How fast is delivery and is ordering guaranteed?

Delivery is asynchronous. Events are enqueued after the redirect completes so the redirect path is never blocked. Nimriz does not guarantee global delivery order or per-resource ordering across event types. Two events for the same link may arrive in any sequence.

Build your receiver to be order-tolerant. Use the created_at timestamp in the envelope to reason about chronological order, and use the before and after field snapshots on link.updated events to determine correct state transitions rather than tracking state on your side.

How do retries work and what happens when an endpoint fails repeatedly?

Nimriz delivers each event at-least-once and retries up to six times total per endpoint. The retry schedule uses exponential backoff: the first retry fires after 60 seconds, then 120, 240, 480, and finally 900 seconds. Retryable outcomes include network failures, missing responses, and HTTP 408, 409, 425, 429, and 5xx responses. Any other non-2xx response causes an immediate terminal failure for that attempt.

After all six attempts are exhausted, the delivery moves to dead-letter state. It will not retry further unless you manually replay it from the endpoint's delivery history view. Replay re-delivers the original event envelope with the same id and payload, a fresh timestamp and signature, and the header X-Nim-Delivery-Reason: replay.

My receiver might get the same event twice. How do I handle duplicates?

Delivery is at-least-once, so your processing must be idempotent. Before executing any side effect, check whether you have already processed an event with the same id value from the envelope. The id is stable across all delivery attempts for the same business event and is preserved on manual replay. Do not dedupe on attempt number or delivery timestamp, as those change on every attempt.

How do I verify that an incoming webhook is genuinely from Nimriz?

Every delivery is signed with HMAC-SHA256. Compute the expected signature by running HMAC-SHA256(signingSecret, "{X-Nim-Timestamp}.{rawRequestBody}") and compare it in constant time against the X-Nim-Signature: v1=<hex> header. Always read the raw request body bytes before parsing JSON, as re-serialization can change byte content and break verification.

You may also enforce a freshness window against X-Nim-Timestamp to reject replayed requests, but remember that legitimate retries and manual replays also use new timestamps on existing event ids. See the webhook docs for a complete Node.js example.

Do I need to write code, or can I connect with Zapier, Make, or n8n?

No custom code is required for the most common recipes. Zapier, Make, and n8n connect to Nimriz using scoped installation tokens available from your integrations settings. Once connected, you can build workflows entirely inside those platforms: trigger on a Nimriz event, then add actions such as posting a Slack message, appending a Google Sheet row, or updating a CRM record. For cases where no matching action exists in those platforms, a Generic HTTP destination can POST events to any HTTPS endpoint with custom headers and payload templates.

Which plan do I need for click-event webhooks?

Click-event webhooks (link.clicked and link.qr_scanned) and Generic HTTP destinations are available on supported plans (Professional and above). Basic lifecycle webhook subscriptions and no-code integration connections are also on supported plans. Check the integrations and destinations feature page or the pricing page for current plan details.

Related use cases

API and workflow automation
Pair workflow triggers with API-driven link creation for end-to-end automation.
Conversion tracking
Use the same event layer to track conversions after the click.
Analytics integration
Feed click and scan events into analytics destinations alongside your workflow triggers.
Webhooks for click and scan events
Build directly on the signed click and scan event webhooks.

Deeper reading

Webhook setup and delivery referenceAPI, webhooks, and automation feature overviewIntegrations and destinationsGlossary: webhookGlossary: event forwardingBlog: Zapier automations for marketing teams

Ready to get started?

Create your account and start with the Starter workflow. Compare plans when you need higher limits or supported-plan capabilities.

Start for freeView pricing