Connections | Charter

Built, then checked with your accountEverything described here is built, with explicit permissions and limits, and tested with the checks we can run ourselves. Before your workspace uses Charter mail, a connected mailbox or a Charter-supplied model, we check it against the real service, including consent, revocation and recovery from an interrupted send, and record the result for your workspace. No such check has finished yet: no mail has left Charter, no mailbox has been connected and no model call has been made outside our own tests. The pilot is invite only while that is true, and we will tell you plainly where each piece stands.

Your email, two ways

Charter runs a mail service of its own. It is not something you authorize, it is part of the product. Every workspace is issued a forwarding address at a Charter domain, and the notification email your website form already sends is what starts the work. The same service carries Charter's notes to you, including the draft waiting for your answer.

A forwarding address, with nothing connected: Point your website form's notification email at the address Charter gives your workspace, or forward it there. Each message that arrives becomes the event that starts a run. There is no consent screen, no account to authorize and no mailbox for Charter to read. Charter sees the messages sent to that address and nothing else.
A connected mailbox: Authorize the Gmail or Microsoft 365 account you already use. Charter watches the inbox for your form's notification, sends the reply you approved from your own account, and checks for the customer's answer so a follow-up stops once they reply.

Who sends the message to your customerOn the forwarding path Charter hands the approved draft back to you and you send it from your own email. Charter does not write to your customer from a domain you have not connected to it. Connect a mailbox and Charter sends from that account, and only then.

Approval runs over the same channel either way. Charter emails you the exact draft with a reference in the subject line. Reply YES, APPROVE or OK and it goes forward. Reply NO or REJECT and it stops. Send back a corrected version inside the marked block the email shows you, and Charter replaces the draft, invalidates the earlier approval and asks again. Only a reply from the address that owns the workspace decides anything, and the approval covers that exact draft: a changed price, recipient or attachment invalidates it. The same review is always waiting in your workspace, so email is a convenience, not the only way in.

The forwarding path is deliberately the first rung. Reading a connected mailbox needs Google app verification and, on Microsoft, your organization's tenant consent; both are open requirements and neither is finished. A forwarding address needs neither permission, so you can start there. Moving to a connected mailbox later changes one setting on the switch. Your four answers stay as they are.

The catalog

Two email paths, and two first-party services that most owners never see. Each row states what it can do, what it needs from you, and the boundary it operates within.

Connection	What it can do	What it needs from you	Operating boundary
Charter forwarding address	Receive the notification email your website form sends. Carry Charter's review emails to you and your replies back.	Nothing to connect. Charter issues your workspace an address at its own domain, and you point the form at it or forward to it.	Charter reads what is sent to that address and has no access to any mailbox. An approved draft comes back to you to send; Charter does not write to your customer on this path.
Gmail or Microsoft 365	Read mail, send the email you approved, check for a reply.	Your Google or Microsoft account, authorized through the provider's own consent screen, plus tenant consent where your organization requires it.	The connection watches the account's inbox folder and reads only mail that arrives after you turn the workflow on, not the mailbox's earlier history.
Aether	Optional. Search authorized knowledge. Retain approved knowledge with its source and provenance.	The Aether address and the knowledge area it may search, plus the identity and API key your Aether administrator issues to Charter. Aether verifies that identity on every request.	Choosing a customer or project narrows what is searched; it never widens access. Retaining knowledge produces a durable receipt from Aether. Charter does not retain knowledge in an Aether service that cannot issue that receipt.
Scoped	Optional. Read a work item. Create work. Publish a comment. Update a work item against an expected version.	Service address, an optional remote workspace ID, and an access token authorized for that workspace.	Work belongs to the granted Scoped workspace. Updates check the expected version so nothing is overwritten; an update whose version cannot be confirmed is not applied.

Aether and Scoped are first-party Charter connections and they are maintained, but they are not part of setting up switches and an owner on that path is never asked about them. They are there for a workspace that already runs those services and asks for them.

No connection is needed for a manual request with supplied files. You can start a run from notes, a CSV, a readable PDF or a photo and keep the result inside Charter.

Where the model comes from

Charter supplies the model. There is no provider account to open, no key to paste, no model to pick and no token prices to enter, and the model settings a configurable workspace has are not part of your setup. Charter holds that side of it.

Use is metered in credits against your plan's allowance. Your workspace shows what has been granted, what has been used and what is left, and every model call is counted against it as the work happens.

The limits are the same ones a workspace with its own key had, and Charter operates them instead of you. An amount is reserved before each call. A single run has a ceiling it cannot pass. A workspace that has used its allowance stops and says so rather than running on quietly. When the cost of a call comes back uncertain, the reservation is held and reconciled against the recorded attempt, never settled by a blind retry.

Bringing your own account

An owner who would rather hold the provider relationship still can. On the configurable tier you supply an OpenAI or Anthropic key, the exact model, its token prices, an output limit and a workspace spending limit. The provider charges your account directly and its own record is the authoritative one, and Charter does not substitute the provider or the model you configured.

On a Charter-supplied workspace, a run whose workflow names a model Charter no longer offers uses Charter's current one instead. The run record says when that happened.

What a Charter-supplied workspace costs is not settled. Pricing for Charter-supplied model access is an open decision, and we will not quote a number we have not decided. Credits, allowances and per-run caps are how the usage is measured; what a plan costs is a separate question, and the pilot stays invite only while it is open.

Connect and repair

Most owners connect nothing. Open Connections in your workspace and it shows your forwarding address to copy into your website form. If you would rather connect the mailbox you already use, Gmail and Microsoft 365 continue through the provider's own authorization screen. Google app verification and Microsoft tenant consent are open requirements that must be met before a mailbox can be read live, and neither is finished. Where one applies to your account, we tell you during pilot onboarding what is in place and what is still pending. Aether and Scoped, if you use them, take the address and scope supplied by their administrator.

The account list shows the authorized account, its status, the time of the last check, and any error that needs your attention, worded so you can act on it. Check access once after setup. When a provider revokes access or an authorization expires:

Reconnect the account from the Connections page.
Point the affected work at the new connection. On the switch path that is the intake setting on the switch; in a workflow you built yourself, each step is rebound explicitly, never assumed.
Simulate the resulting version and read the run record.
Activate the repaired version. Runs already in progress keep their recorded definition.

On the switch path Charter does the last two for you: turning the switch on saves the version, runs the required simulation and activates it in one server-checked sequence, and it stops at whichever of those fails.

Disconnecting a mailbox removes the credentials Charter saved and stops every action that depended on them. You can also review or revoke Charter's access from the provider's own settings. There is nothing to disconnect for a forwarding address: turn the switch off and mail sent there starts nothing.

Where authority comes from

A connected account never grants an automatic outgoing action. Workflow policy does. Each workflow defaults to review for anything that leaves your business, and you may permit one exact action for one step, one connection and one exact input. Customer-supplied text, uploaded files, forwarded email and incoming webhooks are information; none of them can create new authority, and setup cannot grant itself more. A message arriving at your forwarding address can start a run. It cannot decide what the run is allowed to send.

An approval by email is held to the same line. The reply must come from the address that owns the workspace and must answer the review Charter is expecting, and it decides that one draft and nothing else. Charter reads the sending address as the mail provider presents it rather than proving it cryptographically, so treat the reply address in a review email as you would a private link. Turning the email channel off leaves the same approval waiting in your workspace.

Service addresses come from an administrator-controlled allowlist, so a URL typed into a workflow is not unrestricted network access. Credentials are encrypted, bound to the workspace, refreshed one at a time, and kept out of generated prompts and results.

Event intake

A run can start five ways. Each one is chosen when the workflow is reviewed and saved.

Manual: Supply the request and any supporting files when you start the run.
Schedule: Choose a repeat interval and explicitly activate the reviewed workflow. Pausing the workflow stops new starts; a run already underway has its own pause, resume and cancel controls.
Connected mailbox: Choose the connected mailbox as the trigger. Charter records the moment of activation and each message it has handled, so the workflow acts only on mail that arrives after activation. Reconnecting an account does not authorize replaying older messages as new actions.
Forwarding address: Mail sent to your workspace's Charter address becomes an event. The same activation boundary applies: mail that arrived before you turned the workflow on is recorded and not run. A subject or sender filter can narrow what counts, and the same message delivered twice starts one run, not two.
Signed webhook: Choose the external-event trigger, save the workflow, and create its signing key in workflow review. Copy the key once into the sending service. Creating a replacement key invalidates the previous one immediately.

The webhook contract

The sending service posts JSON with a stable id and a data object. The workflow defines how fields inside data map to its inputs.

{
  "id": "evt_2026_000418",
  "data": {
    "name": "Dana Whitfield",
    "email": "dana@example.com",
    "message": "Looking for a quote on an exterior repaint."
  }
}

Each request carries a signature: HMAC-SHA256 over the timestamp, a period, and the raw request body, sent in the x-charter-timestamp and x-charter-signature headers. The workflow's URL and key are bound to your workspace. Timestamps are checked against a replay window, and event IDs are deduplicated durably, so the same event delivered twice starts one run. We supply the exact timestamp format, replay window and request size limits when a webhook is set up during the pilot.

Website builders generally cannot sign a request, which is why the forwarding address, and not the webhook, is the normal path from a website form. The webhook stays available for a sender that can sign, so an existing system can feed an inquiry workflow without a CRM in between.

Receiving an event grants no permission to send or change anything. What the run may send or change is still decided by the workflow's review policy.

Receipts and interrupted actions

A request can fail after the provider has already carried it out. A timeout on a send does not mean the email did not go. Charter is built so that this case is reconciled rather than guessed at.

Before attempting any mutation, Charter records a stable action identity and the intent behind it: which step, which connection, which exact input. After the attempt it keeps the provider's receipt, or an explicit uncertain state when no clear answer came back. Recovery reconciles that same action, checking what the provider recorded, instead of generating a fresh send blindly.

Charter's own mail service follows the same rule. Every message is recorded before it is sent and updated with what came back: accepted, rejected, or explicitly uncertain. Nothing retries on its own. A step that runs again after an interruption answers from the record of the send it already made, so a resumed run does not email you the same draft twice, and an uncertain send stays uncertain until it is reconciled rather than being quietly repeated.

Charter requires the Aether and Scoped services to reject a reused action key with a different input, to permit authorized receipt lookup, and to check versions wherever freshness matters. Charter confirms that a service meets these requirements before it enables writes to it, and no such confirmation has been recorded for an Aether or Scoped service so far. Email providers offer no universal exactly-once guarantee, so Charter keeps the send record and its uncertainty visible instead of pretending otherwise.

Acceptance is not deliveryA send accepted by Gmail, by Microsoft 365 or by Charter's own mail provider is recorded as accepted. It is not confirmation that the recipient received it. The run record says exactly which it was.

Connections.

Your email, two ways

The catalog

Where the model comes from

Bringing your own account

Connect and repair

Where authority comes from

Event intake

The webhook contract

Receipts and interrupted actions

Read next