Actions

How to Create a Webhook Destination with TacTile

A webhook destination fires an HTTP POST with a JSON tap-event payload to an endpoint you control the instant a tap occurs. Two paths: Build (TacTile hosts the endpoint config) or Link (supply your own URL — a Lambda function, a Cloudflare Worker, a custom API route). Prefer no-code? Use a Zap destination instead.

Create your webhook free →
Time10–20 minutes for a working endpoint; longer if you're adding signature verification
DifficultyDeveloper-level — requires an HTTP endpoint you control or write
PathsBuild · Link
Best forEngineers integrating tap events into a backend, data warehouse, or custom logic
Works withAny endpoint that accepts POST + JSON: AWS Lambda, Cloudflare Workers, Vercel/Next.js API routes, custom REST APIs

What is a webhook destination?

A webhook destination is a tap or scan event delivered as an outbound HTTP POST request carrying a JSON payload to a URL you specify. It's an event-driven callback — TacTile is the producer, your endpoint is the consumer, and the tap itself is the event.

65% of organizations building on APIs now generate direct revenue from them, up from 62% the year before.
Postman, 2025 State of the API Report

How to create a webhook destination

Build

TacTile hosts the endpoint config — fastest way to prototype.Recommended

  1. In the TacTile app, tap Create → New Destination.
  2. From the Category picker, choose Developer, then select Webhook from the Type picker.
  3. Choose the Build path.
  4. TacTile generates a unique endpoint identifier tied to this destination and displays your target configuration screen.
  5. Configure request options natively: custom headers, an auth token or secret, and retry behavior, if exposed in this version of the builder.
  6. Set the destination URL where TacTile should forward the event — this can be your own backend endpoint that TacTile calls out to after receiving the tap.
  7. Send a test event from the builder to confirm your endpoint returns a 200 OK.
  8. Tap Save to activate the destination.

Which path should I use?

Use Build if you want TacTile to manage endpoint plumbing (headers, retries, and a generated identifier) without standing up your own route first — useful for prototyping quickly. Use Link if you already have production infrastructure — a Lambda, a Worker, an existing API gateway route — and just want TacTile to POST directly into it with no intermediate layer. Most teams shipping to production infrastructure will prefer Link; Build is the faster path for a proof of concept.

Common use cases

Event warehousing

A Cloudflare Worker receives every tap event and writes it into Postgres or BigQuery for internal analytics, independent of TacTile's own dashboard.

Custom bot notifications

A lightweight serverless function parses the payload and posts a formatted message into an internal Slack or Discord channel with tap metadata (tag ID, timestamp, approximate location).

Self-hosted trigger actions

A tap POSTs to a self-hosted endpoint that then triggers a downstream action in your own systems — for example, updating a dashboard view your team already uses. Treat this as a data-trigger pattern, not an access-control or physical-unlock mechanism; TacTile is not a verified access-control system, and any security-sensitive action downstream is your endpoint's responsibility to gate correctly.

No-connector CRM integration

Internal tools without a native Zapier connector can still ingest tap events directly via a custom endpoint you write and maintain.

Server-side redirect testing

Your endpoint inspects the incoming payload (device type, location, time) and computes which variant a visitor should see before responding — useful for A/B-testing redirect logic outside of TacTile's native routing.

Webhook + analytics

Webhook destinations still report standard tap analytics to your TacTile dashboard — total taps, unique visitors, device breakdown, timing. The metric specific to this type is delivery success rate: the percentage of POST requests that received a 2xx response from your endpoint versus those that timed out or errored, which is your first signal that something downstream broke.

Frequently asked questions

What's the payload schema? Can I see a sample JSON body?
Exact field names are not finalized, but the plausible shape includes an event type, tag ID, ISO 8601 timestamp, approximate location, and device details such as user agent and platform — verify against actual API documentation before relying on field names.
How do I verify the request actually came from TacTile?
Expect a signature header — likely an HMAC signature computed over the raw request body using a shared secret, similar to Stripe's or GitHub's webhook verification pattern.
What response code should my endpoint return?
200 OK, as quickly as possible, to acknowledge receipt. Do heavy processing asynchronously after responding rather than before — treat the webhook handler itself as a thin acknowledgment layer.
Is there a request timeout?
Not confirmed publicly — assume a timeout in the single-digit seconds and design your endpoint to respond fast, queuing any slow work for background processing.
Can I test this without a physical tag?
Likely yes, via a "send test event" action in the builder, but confirm this is available for both Build and Link paths.
Does TacTile retry failed webhook deliveries?
Not confirmed, but the common industry pattern is exponential backoff over a bounded number of attempts before marking the delivery failed.
Are there rate limits per tag or per account?
Not published at this time. If you're expecting high-volume bursts (e.g., a QR code printed in a high-traffic ad placement), confirm rate-limit behavior before launch.

Create your webhook destination — free

Start on the free tier: real, fully functional, no credit card.

Create your free account →