> ## Documentation Index
> Fetch the complete documentation index at: https://docs.teamfollowup.ai/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> Use the public API base URL: https://api.teamfollowup.ai/api.
> Authenticate public API requests with Authorization: Bearer YOUR_API_KEY.
> Use product-owned terms: agents, campaigns, projects (GoHighLevel sub-accounts), contacts, calls, outcomes, skills, cadences, phone numbers.
> Scope requests by locationId rather than projectName.
> Read the guide linked from each API reference group before recommending an endpoint.
# Connecting each project's own assets
> A binding points a shared slot at one project's own calendar, pipeline stage or transfer number. They are matched by name once, at link time, and anything ambiguous is left for you rather than guessed.
The parent says "book an appointment". Which calendar it books onto has to be
answered **per project**, because each sub account owns its own.
That answer is a **binding**.
## Matched once, by name
When a project is first linked, the system compares the primary sub account's
assets with the new one and treats the primary names as canonical. Where a name
matches exactly one asset locally, it binds automatically.
Deliberately conservative, because a wrong guess sends real appointments to the
wrong place:
| Situation | What happens |
| - | - |
| Same name, exactly one local match | Bound automatically |
| No match | Left empty, reported as **missing** |
| Two or more local assets with that name | Left empty, reported as **ambiguous** |
| Transfer destinations | Always manual |
| The CRM could not be read at all | Whole scan reported as **failed** |
An inventory or connection failure is never reported as "missing assets". Missing means
"we looked and it is not there". Failed means "we could not look", and those are
different problems with different fixes.
## After the first link, your bindings win
Name matching runs **once**, when the project is connected. After that the
child's bindings are authoritative and a parent save cannot disturb them.
Parent edits re-check status but never write a binding. So a manual binding
survives every future parent save, including one that name matching could never
have produced, like a child calendar named something completely different.
Two more protections worth knowing:
* **Calendar rules are carried by their condition**, not their position in the
list. Reordering rules on the parent cannot orphan a child's binding.
* **New rules and nodes arrive unbound.** A node you add on the parent reaches
the children carrying no IDs at all, and flags as missing. It never arrives
carrying the parent's IDs.
To change a bound value, change it on that project.
## Why a project will not go live
A child campaign cannot be activated while its binding scan is **pending**,
**needs attention**, or **failed**. Only **ready** clears it.
This is the same idea as the [go live checklist](/campaigns/going-live), applied
per linked project: a campaign that would book into nothing, or into somebody
else's calendar, is stopped before it dials rather than after.
Project Manager is where these show up. If one client out of thirty is showing a
setup warning, this is almost always why.
## In the API
* [Get master agent state](/api-reference/master-agent/get-master-agent-state) lists each linked project with its `masterBindingScanStatus`: `pending` while the scan is queued, `ready` when every asset resolved, `needs_attention` when one could not be matched, and `failed` when the scan itself errored
* [Link a project to this master agent](/api-reference/master-agent/link-a-project-to-this-master-agent) runs the first name match
* [Update campaign](/api-reference/campaigns/update-campaign) on the child sets a binding by hand