Link-in-Bio API for Organizations: Provision, Publish and Revoke Pages Automatically
A link-in-bio API lets an organization create, publish, update and take down bio pages programmatically instead of by hand. With Biotree for Organizations, one Partner API provisions a full page (account, handle, links, socials, background and style, published live) in a single call, updates shared links across everyone at once, and revokes a page the moment a person leaves.
Building one link-in-bio page is a five-minute job in a dashboard. Building a page for every sales rep, member, franchisee or consultant, keeping them all on-brand, and taking them down cleanly when people leave, is not a dashboard job at all. It is a systems job. That is what a link-in-bio API is for.
This article is written for the technical buyer: the engineer or product owner who needs to wire page creation and removal directly into an existing onboarding and offboarding flow. It covers what the API does, what you can set, how shared-link propagation works, and the integration patterns that make it reliable at scale.
What a link-in-bio API actually does
A link-in-bio API exposes the full page lifecycle as programmatic operations, so your own systems create and control pages instead of a human clicking through a dashboard. The central idea behind Biotree for Organizations is ownership: the organization provisions a page for each person, controls what appears on it, and can revoke it. No individual signs up, and no ex-member is left holding a live company page.
That distinction is what makes the API worth having. A consumer tool assumes one person building one page for themselves. An API assumes your platform issuing many pages on behalf of many people, all governed centrally. If you have ever tried to manage a hundred separately owned Linktree accounts, you already know why the API model exists. For the wider strategic picture, see the pillar guide on link in bio for teams and organizations.
The three lifecycle operations
The whole API reduces to three verbs. Everything else is detail on top of them.
Provision
A single call creates the person's account, their page, their handle (which becomes handle.biotree.bio), their links and social icons, the background image and the style, and publishes the page live. There is no separate "create then configure then publish" dance. You pass the person's details from your onboarding data and the page exists, on-brand, in one round trip.
Update
You can update any field on a page after it is live: swap a link, change the bio, point a social icon somewhere new. More importantly, you can update a shared link once and have every page that references it follow instantly. That is covered in its own section below because it is the operation that saves the most work at scale.
Revoke
One call takes a page down. When a person leaves the organization, offboarding revokes the page and the public URL stops resolving. Content is preserved for a clean re-issue if the person returns, but nothing company-branded stays live on the internet under an account you cannot reach.
Provision, update, revoke. Wire those three into the systems you already run and "give everyone a page" stops being a project and becomes a background process.
What you can set on a page via the API
The API is not a thin wrapper that only creates a shell. The full public appearance of the page is settable, so a provisioned page looks finished the moment it goes live, with no manual polishing afterwards.
| Field | What it controls |
|---|---|
| Handle | The subdomain the page lives on (handle.biotree.bio) |
| Profile photo | The person's headshot or the organization's mark |
| Bio | The short description under the name |
| Links | The ordered list of buttons, personal and official |
| Social icons | The row of social platform links |
| Background | A curated background image for the page |
| Style | One of six styles: classic, minimal, bold, soft, modern or warm |
Because style and background are set at provision time, brand consistency is enforced by your integration rather than left to each person's taste. You decide the style once, pass it on every call, and every page in the fleet shares the same visual language. Where you want individuality, you allow the person to add their own social presence and personal links inside that frame.
Updating shared links across every page at once
This is the operation that pays for the whole approach. Some links on a page are personal, such as an individual rep's own booking calendar. Others are official and identical across everyone: the current media kit, the live events page, the seasonal campaign landing page.
Instead of hard-coding those official URLs onto each page, you point them at a single shared source. The page holds a stable link that resolves through that source. When the underlying destination changes, you update it in one place and every page that references it reflects the new target instantly. This redirect indirection means a media-kit link or an events link updated once propagates to the entire fleet without touching a single page individually.
The practical effect: marketing can move a campaign, retire an old PDF, or launch a new event, and every provisioned page is correct the moment they publish the change. No broadcast message asking people to update their own pages, and no stale links pointing at last quarter's material.
Integration patterns: wiring the API into onboarding and offboarding
The reliable way to run this is to treat page lifecycle as a side effect of the identity lifecycle you already manage. A page should come into existence when a person is onboarded and disappear when they are offboarded, with no separate manual step in between.
Provision on onboarding
Hook the provision call into whatever already fires when a person joins: a new record in your HRIS, an approved application in your membership system, a signed franchise agreement in your CRM. The same event that grants their email and access grants their page. Pass the fields you already collected and the page is live before their first day.
Update on change
When a person's details change in the source system, mirror the change to their page with an update call. For anything shared across the fleet, prefer the shared-link approach so a single change covers everyone rather than looping over every page.
Revoke on offboarding
The offboarding step that disables their login should also revoke their page. Tying revocation to the same trigger removes the most common failure mode in this space, which is a company-branded page quietly outliving the person's relationship with the organization. For regulated industries this is a compliance requirement, not a nicety.
Reconcile periodically
As a safety net, run a periodic reconciliation that compares the set of active people in your source of truth against the set of live pages, and provisions or revokes to close any gap. This catches anything a missed webhook or a manual change left inconsistent.
A live example: ProLend
ProLend, a private lending business in South Africa, issues a branded page to every independent consultant it works with. Each consultant gets an on-brand page at their own handle, provisioned and controlled centrally, so the consultant can share one clean link while ProLend keeps ownership of the asset and the official links on it. You can see one live at prolend.biotree.bio.
It is a good illustration of the model in the wild: independent people who represent a brand, each with a page the brand issues and can take down, rather than a scattering of personal accounts the brand has no control over. The same pattern fits sales teams, professional associations, franchise networks and consultant networks equally well.
Get started with the API
Everything above serves one sentence: give every person in your organization an on-brand page, issued, updated and controlled by you. The API is simply the mechanism that makes that true at any scale, by turning provision, update and revoke into calls your own systems make automatically. You keep the ownership, the brand consistency and the clean offboarding, and you keep the consumer strengths that make Biotree pages worth sharing in the first place: fast pages, curated backgrounds, clean design and a genuinely strong free tier.
Create managed Biotree pages for your organization — provision, publish, update and revoke on-brand pages for your whole team, association or network from one API, wired straight into the onboarding and offboarding systems you already run.
Verified members via the API
Provisioning a page can also assert identity. The POST /v1/pages call accepts a verified_member flag alongside organization_name, official_profile_url, job_title and location. Set it for a genuine member and the page renders a "Verified [Org] Consultant" badge and emits verified Person / ProfilePage structured data — the member worksFor your organization, with the official profile as an identity claim.
Leave the flag off and the page provisions exactly as before. Because the fields are part of the same one-call provision, verification costs you no extra integration work — it is one boolean and a few strings in the payload you are already sending.
Related guides
Frequently Asked Questions
What is a link-in-bio API?
A link-in-bio API lets your systems create, publish, update and remove bio pages programmatically instead of building each one by hand in a dashboard. Biotree for Organizations exposes the full lifecycle as three operations: provision, update and revoke. This is what lets an organization issue a page for every person and keep central control of them.
Can I provision a fully built page in one API call?
Yes. A single provision call creates the account, page and handle, sets the links, social icons, profile photo, bio, background and style, and publishes the page live. You pass the details from your onboarding data and the page exists, on-brand, in one round trip, with no separate configuration or publish step needed afterwards.
How do I update one link across every page at once?
Point official links at a single shared source rather than hard-coding the destination on each page. The page holds a stable link that resolves through that source, so when you update the destination once, every page referencing it reflects the change instantly. This is how a media-kit or events link propagates to the whole fleet without per-page edits.
What happens to a page when someone leaves the organization?
Your offboarding process makes a revoke call and the page comes down, so the public URL stops resolving. Content is preserved in case the person returns and needs a clean re-issue, but no company-branded page is left live under an account you cannot control. Tying revocation to the same trigger that disables their login closes the most common compliance gap.
How does the API fit into our existing onboarding systems?
Treat page lifecycle as a side effect of the identity lifecycle you already manage. Hook the provision call into the event that fires when a person joins (an HRIS record, an approved application, a signed agreement) and the revoke call into offboarding. A periodic reconciliation between your source of truth and live pages catches any missed events.