For customer data that isn't on their website and lives in your product (dashboards, help docs, CRM notes), push it in through the Custom Connections API with that customer's token. For data that lives in a system the customer already uses, such as their mailbox, Drive or Notion, connect it as a source instead of copying it through your backend.
You'll almost always want exactly one custom connection per customer: create it once right after provisioning and store the returned connection id as CONN_ID alongside the token. Then upsert documents into it whenever your source data changes.
Request fields
namestringResponse fields
connectionobjectconnection.idintegerCONN_ID and use in every later upsert.connection.namestringconnection.scopestringpersonal for an API account, so its content stays private to that customer.connection.created_by_user_idintegerconnection.post_countinteger0 on creation.connection.last_synced_attimestampnull until the first upsert.connection.created_attimestampContent pushed as a customer is only ever visible to that customer. Personal scope is enforced server-side for API accounts; there is no scope parameter to get wrong.
Shared content across all customers
Organisation-level content is fleet-visible. Anything indexed at organisation level is blended into every customer's results, and every customer's answers can cite it. That is the point (shared help docs, a product glossary, an FAQ), but it also means one customer's data must never be indexed there. If in doubt, push through the customer's token: content pushed as an API account can never leak sideways.
To make something retrievable by every customer, push it as yourself, not as an API account: the partner admin's own custom-connections token (from Settings) creates organisation-level connections. Tenant content in through the customer's token; fleet-wide content through yours.
The same asymmetry applies to namespaces: an API account's note lands in that account's private memory, never the organisation's.