Public documentation and private help
Public documentation describes what Connect is and how it behaves: capabilities, their status, protocols, failure modes. It contains no customer, no message and no key, which is exactly why it can be published. Private help answers questions about your workspace — your records, your settings, your mailboxes — and that can only happen behind sign-in, because the answer is your data.
The line, drawn precisely#
| Public documentation | Private help |
|---|---|
| How a capability works, and its status | Whether it is switched on in your workspace |
| The protocols and formats a developer needs | The keys and endpoints your integration uses |
| What can fail, and what a failure means | Whether it failed for you, and when |
| The shape of a record and what a field means | What is in your records |
| The behaviour of the send boundary | What is waiting in your approvals queue |
The rule that produces both columns is one sentence: a public page may describe the machine, never its contents. That is why no page here carries a customer's name, a message, an address, a telephone number or a key, and why every example uses obviously fictional values.
Why so much is outside the login#
A capability you cannot read about is a capability you cannot evaluate. Putting the substance behind a sign-in makes the product unassessable before purchase and unverifiable afterwards — the reader has to take a sales page's word for what happens when something goes wrong.
- People decide before they sign up. The interesting questions — what happens when a call fails, what an agent is not allowed to do — arrive long before an account does.
- Machines read too. Retrieval systems answering questions about Connect need something true to read; a login page teaches them nothing and they will answer anyway.
- Honesty is easier in public. A status vocabulary that separates *available* from *foundation* from *not yet* only means something if the pages using it can be checked.
- The same corpus serves inside the product. The Assistant has six read-only documentation tools, so an answer in the app can rest on the same text rather than on a second, private version of the truth.
What can never be published#
- Anything from a workspace
- Records, messages, transcripts, files, memory. Not summarised, not anonymised, not as an example.
- Credentials of any kind
- Keys, tokens, endpoints that assume a secret. Examples use plainly fictional values so that nothing real can be copied out of a page.
- A capability that is not there
- A page must not describe something as usable when the code exists and the capability is deliberately narrower. That is what the status word on each page is for.
- A claim nobody can check
- A certification, a customer count, a named reference. If it cannot be evidenced it does not appear, and the absence is deliberate rather than an oversight.
Those constraints are not modesty. They are what make the rest of the corpus worth reading: a manual that would print a customer's message is a manual whose other claims you have no reason to trust.
Getting an answer to a question that spans both#
Ask the public documentation *how does this work*.
Result You get the mechanism, the failure modes and the vocabulary, and you can send the link to somebody who has no account.
Ask the Assistant *what happened here*.
Result It answers from your workspace, under your permissions, citing your records rather than a page.
When the public page and your workspace seem to disagree, check the status word on the page.
Result A capability marked operator-only or foundation behaves differently from one marked available, and that is usually the whole explanation.
For an integration, read the developer material first and keep your own keys out of any question you paste anywhere.
Result The public description is complete enough to build against, and nothing you need to share contains a secret.
Two related notes go further: treating documentation as a build artefact on how this corpus is produced, and writing for people and machines on why the same page has to serve both readers.
Questions#
Is the public documentation a marketing site?
It is written to be checked rather than to persuade. Every page carries a status word, names what can fail, and says when something is not documented instead of filling the gap. Pages that describe a capability as narrower than a reader might hope are the ones doing the most work.
Can an AI assistant elsewhere read these pages?
That is one of the reasons they exist. The site publishes a crawler policy that separates search and user-initiated fetching from model training, and machine-readable descriptions of the interfaces alongside the human pages. What none of them expose is a workspace's contents.
Why does the Assistant sometimes quote documentation at me?
Because the question was about the product rather than about your data. It has read-only documentation tools for exactly that case, which keeps the answer consistent with what everybody else can read instead of being a private paraphrase that might drift.