Your Link in Bio Has an API and an MCP Server Now

You can now open Claude, or Cursor, or any AI assistant that speaks MCP, and say "add my Spotify, put the newsletter signup at the top, and tidy up the grid." A few seconds later your actual ManyLinks page is rearranged. No copy-pasting block settings, no clicking through the editor. You describe the page you want and the assistant builds it.

That is the headline. Under it sits something more durable: ManyLinks now has a real public REST API and a remote MCP server, both documented at /docs/api. If you have ever wanted to script your link-in-bio page, generate it from a config file, or wire it into the rest of your stack, you can. If you have never touched an API in your life, you can still get the benefit by talking to an AI client in plain English.

Let me walk through what shipped, what MCP actually is (without the buzzword fog), and the one honest caveat before you get excited.

What actually shipped

Three things, really.

A public REST API lives at https://api.manylinks.io/v1. It follows an OpenAPI 3.1 spec you can read at /v1/openapi.json, and the interactive reference is at /docs/api. You authenticate with a Bearer key (Authorization: Bearer ml_live_...) that you generate yourself in Settings under the Integrations dialog. Keys are scoped, so a key you hand to one tool can be read-only while another can write.

A remote MCP server lives at https://manylinks.io/api/mcp. It uses Streamable HTTP and the same API key for auth. This is the part that lets an AI assistant operate your page directly.

And webhooks, which fire real-time signed events when your page changes. Those are a Pro feature, and I will come back to them.

The design choice worth noting: the MCP server is not a separate codebase reimplementing everything. Each MCP tool proxies to the same /v1 REST endpoints and forwards your key. So whatever rules apply to the API (auth, scopes, rate limits, the Pro check) apply identically through MCP. One source of truth, two front doors.

What MCP is, in plain terms

MCP is the Model Context Protocol. Anthropic introduced and open-sourced it on November 25, 2024 as "an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools". The short version: it is a common language for letting an AI assistant call external tools and read external data, instead of every app inventing its own bespoke plugin format.

For connection details, use your client's current MCP documentation. ManyLinks requires a remote Streamable HTTP connection that can send an Authorization Bearer header. Client support and authentication setup vary; a URL alone is not enough.

Here is the mental model. Without MCP, an AI assistant can write you the steps to update your page, but it cannot press the buttons. With an MCP server connected, the assistant gets a set of typed tools (think of them as functions it is allowed to call) and it can actually do the work. The server decides which tools exist and what they are permitted to touch. You stay in control because the tools only do what the server allows and your key only carries the scopes you granted.

The part that feels like magic

Connect the ManyLinks MCP server to your AI client of choice, point it at your API key, and then just talk.

"Add a link block to my newsletter and pin it to the top." Done. "Paste my latest YouTube channel and let it auto-fetch my newest video." Done. "My grid is a mess on mobile, line the social links up in two columns." It reads your current layout, computes new positions, and writes them back.

Concretely, an assistant working through MCP can read who it is building for (get_my_profile), inspect what is already on the page (list_blocks, get_block), look at a reference page for inspiration (get_page, which reads any public ManyLinks page by username), then create, update, and delete blocks and rearrange the grid. It can write link, image, text, title, and map blocks. The rich cards (Spotify, GitHub, Airbnb, and the rest of the live blocks) are link blocks whose URL gets enriched on our side, so the assistant creates a link block with the right URL. Enrichment is asynchronous, depends on available source data and feature availability, and social refreshes follow the account's plan cadence.

After you create a key, ManyLinks offers client install links and a copyable configuration snippet. Use a client that accepts the remote URL and Bearer header shown in /docs/api. Do not assume every custom-connector interface accepts a static API key; check its authentication options first.

What a real exchange looks like

Picture a musician who just dropped a single. They open their assistant and type: "Look at my page, add a link block for the new release on top, set my Spotify card below it, and move the merch link under that." The assistant calls get_my_profile to confirm whose page it is, list_blocks to see what already exists, then create_block for the release link, another create_block with the Spotify URL so the live card renders, and update_layout to set the new grid positions. The whole thing is one message and a short wait.

The same flow works for a one-time bulk job. Hand the assistant a list of fifteen links from a spreadsheet and ask it to build the page, and it will loop through create_block calls and arrange them. That is the moment the API earns its keep: not the first single edit, but the tenth, or the page you rebuild from scratch in a minute instead of an afternoon.

What is free and what needs Pro

This is the part people get wrong, so I want to be exact.

Building and editing your page is free on any plan. The profile, blocks, and layout tools work on a free account. An AI assistant can create and arrange the supported block types on a free account. Uploading new media still requires the visual editor, and separately gated features keep their own requirements. That is deliberate. The API and MCP are not a paywalled upsell. They are how ManyLinks works.

Only two things require Pro: reading analytics and managing webhooks. The Pro check runs per request, so the moment a downgrade happens those calls start returning a clean 403 pro_required while everything else keeps working.

Capability	Free	Pro
Read your profile and blocks	Yes	Yes
Create, update, delete blocks	Yes	Yes
Reorder the grid layout	Yes	Yes
Update display name and bio	Yes	Yes
Read any public page	Yes	Yes
Read your analytics	No	Yes
Create and manage webhooks	No	Yes

These are the public page-building tools. Admin-only tools require an admin account and are not granted to an ordinary key by upgrading to Pro.

Scopes are how you keep this safe. When you mint a key in the UI it defaults to profile:read and blocks:read, the most cautious pair, and you add write scopes only if you want the assistant to actually change things. There are seven scopes in total (profile:read, profile:write, blocks:read, blocks:write, analytics:read, webhooks:read, webhooks:write), so you can hand a read-only key to one tool and a full read-write key to another. The plaintext key is shown exactly once at creation; after that only a hash is stored, which means we cannot recover it for you. Copy it into a password manager the moment you see it.

A few details builders will care about

If you are the kind of person who reads error formats for fun, here is what to expect.

Errors are RFC 9457 problem documents (application/problem+json) with codes like invalid_api_key, insufficient_scope, pro_required, rate_limited, and validation_error. Rate limiting is per-key, surfaced through RateLimit-* headers with a Retry-After on a 429. List endpoints use cursor pagination and return { data, nextCursor, hasMore }. Every response carries an X-ManyLinks-Version header.

The version lives in the path (/v1). Breaking changes ship as /v2 with a minimum six-month deprecation window and Deprecation/Sunset headers, so a script you write today does not quietly break next quarter.

One real limitation to flag: media upload stays in the visual editor. The API sets metadata but does not upload avatars or block images. If an assistant creates an image block, it creates the block without the image file, and you add the picture in the editor. Image cropping and our pixel-snapping tricks depend on the UI path, so we kept upload there on purpose rather than half-supporting it over the API.

Webhooks, for the automation crowd

Webhooks are the Pro half of this. Register an HTTPS endpoint and ManyLinks will POST a signed event whenever your page changes: block.created, block.updated, block.deleted, profile.updated, layout.updated, and enrichment.completed or enrichment.failed. Those enrichment events currently apply to asynchronous image-block media processing, not every social-card refresh.

Deliveries carry an HMAC-SHA256 signature in the ManyLinks-Signature header (t=<timestamp>,v1=<hmac>). Verify the raw body and timestamp before trusting an event. Failed deliveries retry with backoff and persistently failing endpoints can be disabled. See /docs/api for the supported event shapes and delivery behavior.

What is this for? Mirroring page changes into a CMS, posting to Slack when a block goes live, kicking off a build when your profile updates. It is plumbing for people who already have a workflow to plug it into. If that is not you, ignore it.

Why this matters for the category

A page-building API is useful when you repeat edits: rotating campaign links, preparing a page from structured data, or applying a consistent layout. MCP makes those operations available to a compatible assistant, using the same scoped permissions as a script.

The useful question is whether your workflow needs automation. If you already maintain links in a spreadsheet or ask an assistant to prepare content, connecting the page saves another round of manual entry. The Linktree comparison covers the wider product differences.

The honest caveat

This is most useful if you already use an AI coding or assistant tool. If MCP, Cursor, and API keys are unfamiliar territory, the practical payoff is small today, and that is fine. The visual editor is still the primary way to build a page, it is faster for most edits, and nothing about the API changes that. You lose nothing by skipping this entirely.

There is also a learning curve even for technical users. The first time you wire up an MCP client and figure out scopes takes a few minutes of fiddling. The payoff comes on the second and third page, or when you script ten pages from one config, not on the very first edit.

So: if you build with AI tools already, generate an API key and connect the MCP server on a free account. Ask your assistant to add one block and watch it land on your page. If that is not your world, keep using the editor and read the analytics guide instead. Both paths lead to the same page.