LnkApp

Product

How it works: edge, API, webhooks

The working surface: links resolved at the edge, a full API, webhooks, analytics, and service levels measured continuously in the product.

How a link resolves

When someone clicks your link, the request reaches the nearest edge city and the redirect resolves right there. The visitor lands at the destination without a detour to a distant origin server. That is the whole mechanism — short path, measured result.

  • Links resolve at the Cloudflare edge - 300+ cities Verifiable · quarterly
In depth

Follow one click end to end.

1. Request. A visitor clicks your link — from a campaign, an invoice, a QR code. 2. Edge. The request arrives at the nearest edge location, where your redirect rules already live. Resolution happens there, close to the visitor, wherever they are. 3. Destination. The visitor lands. The redirect recorded what it needed for your analytics on the way through.

Because resolution happens at the edge rather than at a single origin, distance stops being the dominant cost. The latency figure below is measured from live redirect telemetry — percentiles from production traffic, not a benchmark run.

Service levels, measured

This is not a summary we wrote — service levels are measured continuously, straight from the product's own telemetry surface, and surfaced through its API. If you are deciding whether your traffic is safe with us, decide on the measurements, not on our adjectives.

  • Service levels are measured and visible - watch them yourself Measured · live
In depth

Every service level we publish is measured continuously and surfaced through the product API. The measurement you act on is the current one, read straight from that surface in the product — with its source and timestamp, not a marketing snapshot. There is no separate feed for the website.

Two properties matter for a reliability review:

  • The metrics are live. They come straight from product telemetry, so the figure you act on is the figure in production right now — not a number we typed.
  • The metrics stay visible. Watching them is not an evaluation-day privilege — the point of the claim is that you can keep watching after you sign up.

Webhooks that close the loop

Events push into your systems with the failure handling already engineered: retries when your endpoint has a bad moment, circuit breakers when it has a bad hour, dead-letter queues so nothing vanishes silently. You build the consumer; delivery discipline is our job.

  • Webhooks with delivery guarantees: retries, circuit breakers, dead-letter queues Verifiable · per-release
In depth

A webhook system is judged by what happens when the receiving end misbehaves. This one is engineered for exactly that day:

  • Retries. Transient failures on your side are retried — a blip does not cost you the event.
  • Circuit breakers. A persistently failing endpoint is isolated instead of hammered, and delivery resumes sanely when it recovers.
  • Dead-letter queues. Events that exhaust their delivery attempts land somewhere inspectable — failure is visible and recoverable, never silent.

The delivery behavior is part of the documented API surface, so what your integration can rely on is written down, not folklore.

Analytics from the real dashboard

Your analytics come from the product's own dashboard, not an illustration of one. Every link carries its record of what happened, and the view is built to answer working questions. The data behind it is yours: export everything, anytime.

  • Your domain, your data: export everything, anytime Verifiable · per-release
In depth

Analytics here follows two rules.

First, show the real thing. The analytics are the dashboard as it exists in the product — real surfaces, honest numbers. If the product cannot demonstrate it, this page does not claim it.

Second, the data is yours beyond the dashboard. Every view you can read, you can also take with you: the export is complete and available on your schedule. Analytics that only exists inside our walls would be a soft form of holding your data — so it does not work that way.

A link in one API call

One authenticated call creates a link. From there, the rule is parity: everything you can do in the dashboard, you can do in the API. Build against the documented v1 surface and the dashboard never becomes a manual step in your pipeline. Read the docs.

  • Everything in the dashboard is in the API Verifiable · per-release
In depth

The API is the product, not a companion feature. The parity rule is deliberate and testable: if the dashboard can do it, the API can do it — links, custom domains, analytics reads, and webhook configuration included.

What that means in practice:

  • Automation is first-class. Anything your team clicks today can become a call in your deployment or campaign pipeline tomorrow.
  • The docs are the contract. The public API documentation covers the v1 surface and moves with each release — start at the quickstart, which takes you from a key to a resolving link in one call.
  • Events flow back. Pair the API with webhooks to close the loop into your own systems.

Read the docs.