# Provider

A **provider** is the external service that actually carries a [channel](/docs/glossary/channel/): Gmail or Microsoft Graph or an IMAP and SMTP server for email, a WhatsApp Business provider for WhatsApp, a [carrier](/docs/glossary/carrier/) for the telephone. Connect speaks to each through an adapter, and what the provider returns is translated into Connect's own records before anything downstream reads it.

- **Status:** Available
- **Audience:** both
- **In the app:** #/integrations
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/glossary/provider/

## Two copies of the same mail, on purpose

A message exists twice in the database. One copy is what the provider's adapter stored, in the provider's own shape — Gmail's ids and labels, Graph's delta tokens, an IMAP server's UIDs. The other is the canonical thread and message that the engine and the screens read. A bridge copies between them.

This looks like duplication and is the reason provider changes are cheap. The reasoning loop, the drafting, the relationship records and the screens have never seen a provider's vocabulary, so adding a provider is a new adapter and a new bridge, not a change to anything after them. It is also why a provider's own quirks — a history id that jumps, a UID validity that resets — are contained where they arise rather than leaking into your conversation history.

> **Note** Provider credentials are sealed on every save and are never echoed back to a screen. A page that shows a connection as configured is showing state, never the secret behind it.

## What differs between providers, and what does not

| Depends on the provider | Does not |
|---|---|
| Whether a capability exists at all — SMS, call recording, transfer | The autonomy rules that decide whether Connect may use it |
| How new mail is discovered, and what a lost cursor costs | What a thread looks like once the mail has arrived |
| The exact acknowledgement that proves a send happened | That a send is not called sent without one |
| Which errors are retryable and what they are called | That a retried action is made safe to repeat |

The right-hand column is the invariant worth trusting. A capability the provider does not offer is reported as absent rather than simulated: Connect does not fake a feature to keep a screen tidy, which is why the [SMS](/docs/sms/) and call-recording positions are stated plainly rather than being softened.

## Provider, carrier, model, integration

**A [carrier](/docs/glossary/carrier/)** — A provider, narrowed to telephony. Every carrier is a provider; most providers are not carriers. Say carrier when the sentence is about the telephone network.
**A model provider** — The company behind the language or speech model. It is not a communication channel, it never sees a mailbox, and its costs are metered separately from anything a channel costs.
**An integration key** — A credential *you* issue so something else can call Connect. A provider is a service Connect calls outward to. The arrows point in opposite directions — see [integration keys](/developers/integration-keys/).
**A [channel](/docs/glossary/channel/)** — The medium. WhatsApp is a channel; the business platform behind it is the provider.

## Questions

### Can one workspace use several providers on one channel?

On email, yes — mailboxes are connected individually, and a workspace can hold a Gmail account and an IMAP account at once. Each mailbox has its own provider and its own sync position.

### What happens to my history if a provider is changed?

The canonical threads and messages stay, because they were never in the provider's shape. What restarts is discovery of new mail from the new account, with a fresh sync position.

### Does Connect name its providers publicly?

Where the answer changes what you can do, yes — the mail providers and the live carrier's SMS position are stated. Provider choice is otherwise an implementation matter, and [designing telephony that does not name its provider](/research/provider-independent-telephony/) explains why the code is written that way.

## Related

- [Channel](https://connectbyjbrh.com/docs/glossary/channel/)
- [Carrier](https://connectbyjbrh.com/docs/glossary/carrier/)
- [Mailbox](https://connectbyjbrh.com/docs/glossary/mailbox/)
- [Technology reference](https://connectbyjbrh.com/docs/technology/)
- [Designing telephony that does not name its provider](https://connectbyjbrh.com/research/provider-independent-telephony/)

## What this page is based on

- docs-source/sources/GENERAL.md §3 — provider tables, canonical records, the bridge
- docs-source/sources/GENERAL.md §10 — provider credentials sealed on save
- `docs-source/facts.py` — CHANNELS providers per channel
