Linktree data.
And where every link really goes.

Here it means one HTTP endpoint that reads any public link-in-bio page and returns it as clean JSON: the creator’s name, bio and avatar, the page’s look, what it sells, and every link on it with its label, position, grouping and destination. You send the page address with a Bearer token and get back typed records. It is not Linktree’s API — there is no app to register and no account on any of these services.

Four in this release: Linktree, which is the richest by some distance, plus Lnk.Bio, AllMyLinks and solo.to. Twenty-six more are recognised but not readable, and the API tells you which and why rather than failing on them — closed to anonymous visitors (Beacons, HeyLink, Direct.me, Lynk.id), publishing no links in the page itself (Komi, Pillar, Bio.fm), shut down (Bento, Linkpop, ContactInBio, Tap.bio), or not a link aggregator at all (Carrd). That second list matters more than it sounds: a caller with a pile of bento.me addresses is told the service closed and redirects to Linktree, instead of burning a fetch on each one.

The full page address — https://linktr.ee/spotify, or linktr.ee/spotify. A bare handle is a 400 saying exactly why: "Handles are not unique across services, so 'nike' is ambiguous. Pass the full profile URL, or name the provider." The same handle exists on a dozen services, so guessing which one you meant would be worse than asking. If a handle really is all you have, send provider alongside it.

At profile.links[] on the /profile route, and at links[] on the /links route. The count is profile.linkCount or linkCount to match, the creator’s name is profile.identity.displayName, and notes[] and pagesFetched are at the top level on both. This is the one thing people get wrong often enough that the docs open with a table of it.

You get a 200 with linkCount 0 and a note saying "This page is live and published no links." — and it genuinely means empty. A page whose link list could not be read at all returns a 502 instead. The two are deliberately different statuses, so a zero is never a possible parser regression in disguise: you can alert on 502 and ignore the zero.

Because that is what those creators published. Read on 16 September 2026: linktr.ee/selenagomez returned 68 links, shakira 11, spotify 6, adidas 6, nike 3, and bbc 0 — a live handle with nothing on it. All six were a 200. The spread is the data, not a limit of the reader, and every response says which of the two it is.

Yes, and it is the part almost nothing else does. Set resolveDestinations and every link gains a destination: the final url, its host, every hop in order, the page title, and a flag for whether the chain passed through a link shortener or an affiliate redirector. That is how you find the retailer or network at the end of a campaign link rather than the wrapper at the start. For a single link, /unwrap-link does the same job on its own, up to 20 hops. It is off by default on the page routes because it turns one fetch into one request per link.

One credit per page fetched, stated on every response as pagesFetched. Reading a page costs 1 whether it has 68 links or none. /resolve-url fetches nothing at all and is free, and /detect-provider reports pagesFetched 0 when it recognised the address from its shape alone. There is no per-run start fee and no separate charge for a filter.

Yes. All five routes are MCP tools on the same FetchLayer MCP server, named linkinbio_profile, linkinbio_links, linkinbio_detect_provider, linkinbio_unwrap_link and linkinbio_resolve_url. Tool calls use the same key and are billed exactly like REST.

Every route is monitored 24/7 and a failure alerts our team, and you are only charged for successful responses. The error statuses are specific rather than generic: a 400 names the field or the reason a service cannot be read, a 404 means no page exists at that address, a 502 means the page was fetched but not parsed, and a 503 means the service was briefly unavailable.