How it works
One redirect, unlimited possibilities.
The mechanics, for anyone evaluating this rather than buying it. Evaluation order, status codes, what an unfurler gets instead of a redirect, and what we store.
The hot path
What happens when somebody clicks.
- 01
The request lands
A GET for fixedl.ink/:slug, or your own domain, at whichever edge location is nearest the visitor. No session is involved and none is read, because short links never require one.
- 02
The slug is resolved
One lookup for a live link. On our domain a slug is global; on your domain it is scoped to that hostname, so two customers can both own /spring.
- 03
Rules are evaluated
Top to bottom, first match wins. Every condition on a rule must hold. Matching nothing is normal and gets the link’s own destination.
- 04
The redirect goes out
HTTP 302, not 301. A 301 is cached by browsers and intermediaries more or less permanently, which would make the destination un-editable. Keeping it editable is the whole point of this product.
- 05
The click is recorded after the response
The visitor is already on their way before anything is written down. Recording a click is never allowed to slow one, and never allowed to fail one.
A slug that does not resolve is a 307 to the home page carrying a notfound flag, rather than a bare 404. Someone holding a mistyped link off a poster gets told what happened instead of a browser error page.
Routing rules
How one click gets resolved.
Rules are checked in the order you put them in, and the first whose conditions all hold decides where the visitor goes. Nothing matching is a normal outcome rather than a failure, so adding a rule can never make an existing link stop working.
What a rule can test
Conditions on one rule are ANDed. To express “or”, add a second rule. That keeps each one readable in the dashboard, and keeps the order meaningful.
Everything here is decided from the request itself, close to the visitor. There is no round trip to a rules service and no client-side redirect.
- Country
- Worked out where the request arrives. We never look up an IP ourselves.
- Device
- Mobile, tablet or desktop.
- OS and browser
- iOS, Android, macOS, Windows; Chrome, Safari, Firefox, Edge.
- Language
- The languages the browser asks for, most preferred first.
- Referrer
- The referring host, so t.co and x.com are separable.
- Date window
- Absolute from/to instants. The one that makes printed codes survive.
- Time of day
- A window in a named time zone, which may wrap past midnight.
- Weekday
- Days of the week, evaluated in that same zone.
Crawlers and unfurlers
A preview page, not a redirect.
An unfurler reads metadata without following redirects. Sent a 302 it would either show no card at all, or build one from the destination’s tags, never the ones you set on the link.
So a request from a known crawler gets an HTML page carrying the link’s own Open Graph tags, with a meta refresh so a human who lands on it still arrives at the destination. If the link has no preview worth showing, it falls through and is treated like any other visitor.
Rules are evaluated against the crawler, because it is the only visitor that request has. Date windows behave exactly as intended, so a poster whose sale has ended unfurls with the post-sale copy. A device rule will essentially never match a crawler, so it leaves the card alone.
Cached for five minutes
Unfurlers cache aggressively on their own account. A short TTL on our side means an edited preview appears in minutes rather than days.
Per rule, as well as per link
A routing rule can carry its own title, description and image. Fields it leaves null fall back to the link’s, so a rule only states what differs.
Custom domains
What connecting one looks like.
Two records
A CNAME pointing the hostname at the edge, and a TXT proving you control it. Both are shown to you with their values filled in.
Certificates
Issued once the records verify, and renewed without you. The dashboard shows the hostname and certificate states separately, because they fail separately.
Separate from the app
Short links are served from a different registrable domain than the dashboard, so nothing a link points at ever shares an origin or a cookie scope with a signed-in session.
What is stored
A click, and what it becomes.
One record per redirect. The link, the time, the country, the referring host, and the device, browser and operating system. All of it is worked out as the click comes in, which is what keeps the dashboard fast on the way back out.
The visitor is an anonymous identifier, not their address. Counting unique visitors needs something stable, not something that identifies a person, and the address itself is never stored.
Anything older than your plan’s retention is deleted.
- Retention on Free
- 30 days
- Retention on Pro
- a year
- Retention on Enterprise
- as long as your policy says
Next
Build on it.
Links, domains, routing rules and analytics are all reachable over the REST API, from the same endpoints the dashboard uses.
Looking for who uses it and what for? That is solutions.