Linktree data.
And where every link really goes.
Every link on a Linktree, Lnk.Bio, AllMyLinks or solo.to page — in order, with its label, and the destination it truly lands on after the redirects. Clean JSON via REST or MCP.
Trusted by developers shipping real products.
247,095 served today
Request
$ curl -X POST \ https://api.fetchlayer.dev/link-in-bio/links \ -H "Authorization: Bearer ss-your-key" \ -H "Content-Type: application/json" \ -d '{"profile":"https://linktr.ee/spotify", "resolveDestinations":true}'
Response
{
"provider": "linktree", "handle": "spotify",
"links": [{
"kind": "link", "title": "Playlist 1",
"position": 0, "tracked": false,
"destination": {
"host": "open.spotify.com", "status": 200,
"title": "Spotify", "shortened": false
}
}, …5 more],
"linkCount": 6, "totalLinks": 6,
"destinationsResolved": true, "pagesFetched": 1
} Built for feedback workflows
Fetch the public signal. Use it wherever your team works.
Where the link really goes
Set resolveDestinations and every link gains its final url, host, hop chain, page title and a flag for whether a shortener or affiliate redirector was involved. A page sends you to lnk.to; lnk.to sends you to Spotify. Almost nothing else follows that chain, and nothing else follows it on Linktree.
One shape for every service
A link page is the same object wherever it is hosted: a creator, a bio and a list of outbound links. Linktree, Lnk.Bio, AllMyLinks and solo.to all come back in the same record, so you write one parser rather than four — and a service that rebrands keeps its provider id, so stored values do not break.
The creator, not just the list
One call returns the page whole: the creator’s name, handle, avatar and bio, the colours and font they chose, the social icon row, whether they sell products or take tips, and every link in the order it appears. Enough to profile a creator, not just to harvest their URLs.
Thirty services recognised
Paste any link-in-bio address and you are told which service it belongs to. Linktree, Lnk.Bio, AllMyLinks and solo.to pages are read in full. The rest are named, with what stands in the way — a service that shows nothing to an anonymous visitor, one that builds its links in the browser, or one that shut down — so an address is always answered rather than silently failing.
Monetization, in the open
Every entry says whether clicks are routed through the service’s own tracker, whether the link earns the creator money, what it costs where it sells something, and what gate stands in front of it. The page-level record adds whether the creator sells products or takes tips at all.
Triage before you fetch
/resolve-url parses an address and says whether it can be read, without making a single request — so a list of pasted addresses is sorted into readable and not before a page fetch is spent. It is free, and it answers in milliseconds.
See what a creator actually promotes—then export it to CSV.
Prefer not to write code? Paste a link page address into FetchLayer Research Chat, ask where the traffic really goes, and get a clean table of every link and its destination.
- ✓Ask questions in plain English
- ✓Analyze themes, sentiment, and pain points
- ✓Download the structured results as CSV or JSON
No code or setup required · Uses your FetchLayer credits
Read these 8 Linktree pages, follow every link to its real destination, and tell me which retailers, affiliate networks and platforms each creator sends traffic to. Flag the monetized and click-tracked links. Export as CSV.
I read each page and followed every link through its redirects. The table gives the creator, the link label, its position on the page, the wrapper URL, the destination host and title, and whether the link is monetized or click-tracked. One page was live with no links at all, and it is marked as such rather than dropped.
link-in-bio-destinations.csv
8 creators · 7 columns · ready to download
Solutions
Build the workflow around the feedback.
Where the link lives
Instagram profiles and their bio links, reels with play counts, and the posts that drive people to the page in the first place.
Explore →The other bio link
TikTok account profiles carry a bioLink too — the same creator, the other feed, on the same key.
Explore →The other end of the link
Once a destination resolves to a retailer, read the product itself — price, title and availability.
Explore →From raw feedback to action
One request is the start of the workflow.
Store the structured response, run it on a schedule, pass it to an LLM, or feed it into the system your team already uses. FetchLayer handles retrieval so you can focus on the outcome.
- 01
Sort the addresses
Run the list through /resolve-url. It fetches nothing, costs nothing, and tells you which addresses name a readable page and which name a service that is walled, client-side or closed.
- 02
Read the page
One request returns the creator, the page and every link in its own order. Pass resolveDestinations when you want the retailer at the end of each link rather than the wrapper at the start — that is one request per link, so decide deliberately.
- 03
Watch it change
A link page is the one surface a creator edits constantly. Read it on a schedule and diff: a new affiliate network, a dropped sponsor, a campaign link that went live this morning. Store what you read — the page keeps no history for you.
MCP & agents
Your AI already knows
how to use this.
Use the Link in Bio endpoint directly from your MCP-compatible agent. Ask it to retrieve public feedback, identify patterns, and turn the result into a useful brief without writing integration glue.
Pick your editor and we hand you the config with your key already in it — no JSON to hand-edit, no wrapper code.
Get your free API keyFree tier · no credit card · any MCP host
What is Spotify promoting on their Linktree, and where do those links actually go?
Six links, all of them playlists. Every one resolves to open.spotify.com after its redirect, with the page title read at the far end — none are click-tracked and none are monetized. One request, one credit: the destinations came back with the links.
Works with every MCP-compatible tool
Use cases
What teams build with link-page data.
Same API, endless applications. Here is what teams ship once they can see where a creator actually sends traffic.
Creator monetization audits
Follow every link on a creator’s page to where it really lands and see which retailers and affiliate networks they send traffic to — plus which links are click-tracked and which earn them money.
Sponsor and partner discovery
The link page is where a partnership becomes public first. Read a roster of creators and group their destinations by host to see who is working with whom.
Campaign link tracking
Re-read a page on a schedule and diff it: a campaign link that went live this morning, a sponsor that quietly disappeared, a product that moved to the top of the page.
Lead enrichment from a bio link
A profile gives you one URL. Resolve it, read the page behind it, and turn one link into the creator’s whole outbound surface — site, shop, newsletter, socials.
Address triage at scale
A list of pasted link pages spans a dozen services, several of which have shut down. Sort them for free before spending a fetch, and be told which are walled, client-side or closed.
Redirect and shortener analysis
Follow any shortened or campaign link to the end of its chain and record each hop, so a wrapper is never mistaken for a destination in a report.
Compare approaches
Spend time on the insight, not the collection layer.
| What you need | FetchLayer | Official API | Build it yourself |
|---|---|---|---|
| Public pages with no login | ✓ | No public API | You run the fetchers |
| Links resolved to their real destination | ✓ | n/a | You follow the chains |
| Which service an address belongs to | ✓ | n/a | You maintain the list |
| Empty page distinguished from failed read | ✓ | n/a | You detect it |
| Ready for AI and MCP workflows | ✓ | n/a | Your integration |
FetchLayer provides access to publicly available data. It is not affiliated with, endorsed by, or sponsored by the platform.
Pricing
Start free. Scale when ready.
Pay per request with no commitment, or lock in a flat monthly rate with built-in savings.
Free plan — 30 requests
Verify responses, inspect the API, no credit card required.
Pay as you go
$1.99
per 1,000 requests
$0.00199 per request · credits never expire
How credits work — no multipliers
One credit = one API call, on every endpoint and platform. No matter how many results come back, you pay for the call, not the output size. Most scraping APIs charge multipliers of 5x, 25x, even 75x per call depending on the target — here it's always 1.
- No multipliers — 1 request = 1 credit
- No monthly commitment
- Credits never expire
- Same API & MCP access as subscribers
- ∞ req/min, ∞ API keys
∞
Expiry
Credits stay until you use them. No monthly reset, no pressure to hit a quota.
0
Commitments
No subscription, no contract, no minimums. Start, pause, or scale whenever.
100%
Access
Every endpoint and MCP included. Not a limited tier — same data as any subscriber.
API reference
Every parameter, documented.
All requests are POST with a JSON body and Bearer auth header.
POST /link-in-bio/links Just the link list for a page — and on this route links sits at the top level. Each entry carries its kind, label, description, url, position, grouping, thumbnail, whether clicks are tracked, whether it is monetized, its price where it sells something, and any gate on it.
profile* string The full page address, e.g. https://linktr.ee/spotify — not a bare handle kind string 'link' | 'embed' | 'product' | 'social' | 'heading' | 'group' limit number Maximum links, up to 500, or -1 for the maximum. Defaults to 100. resolveDestinations boolean Follow every link through its redirects to where it really lands. POST /link-in-bio/profile One page in full: the creator’s identity, the page’s colours and font, whether it sells anything or takes tips, any gate in front of it, the social icon row, and every link. The link list is at profile.links[] and the count at profile.linkCount — not at the root.
profile* string The full page address — not a bare handle provider string Required only when profile is a handle rather than an address resolveDestinations boolean Follow every link to its real destination. POST /link-in-bio/unwrap-link Follow one link through its redirects and report where it lands: the final url, its host and page title, every hop in order, and whether the chain went through a shortener or an affiliate redirector.
url* string The link to follow maxHops number How many redirects to follow, up to 20. Defaults to 10. POST /link-in-bio/detect-provider Which service an address belongs to, whether its pages can be read, and where they cannot, why — walled behind bot checks, rendered client-side, shut down, or not a link aggregator at all. Thirty services recognised.
url* string Any address to identify checkCustomDomain boolean Also fetch the page, so a link page on the creator's own domain is recognised. POST /link-in-bio/resolve-url Parse any address into request fields and say whether it can be read at all, without fetching anything. The right first pass over a list of pasted addresses, before a single page fetch is spent. Free.
url* string Any address to parse Fields marked * are required. Full API reference →
FAQ
Common questions.
What is a link-in-bio API?
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.
Which services can you actually read?
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.
Do I pass a handle or a URL?
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.
Where are the links in the response?
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.
What happens when a page has no links?
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.
Why do some pages return three links and others sixty-eight?
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.
Can you tell me where a link actually goes?
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.
How does billing work?
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. Link in Bio is in Beta while coverage expands, billed at half credit.
Can my AI agent use it?
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.
How reliable is it?
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.
Start pulling Link page data today.
Get a free API key, make your first request, and put public feedback to work in your own product or research workflow.
Used by developers at
Individual developers or teams — not official partnerships