How installation normally works
What a forward deployed engineer does by hand today.
No install and no redirect. The customer receives a server URL and a token and creates a connector in ChatGPT settings.
IntegrationsChatGPT
ChatGPT
The same shape as Claude, and deliberately a separate destination: a vendor can sell one without the other, and revoking one must not touch the other.
PreviewSee the deployment model
MeetextDestination network Live
One productevery customer workspaceClaudeChatGPTAtlassianGoogle ChatHubSpotMicrosoft 365SalesforceServiceNowSlack
✓Customer scoped✓Least privilege✓Continuously checked
Available today
The adapter is real and something is incomplete, either a part of the destination or real-provider proof for part of the lifecycle. The gap is stated on the page rather than discovered during an evaluation.
The adapter is complete and every path is covered by tests against a provider simulator, which proves our logic and not the provider's. Not yet exercised with real provider credentials: authorization, installation, execution, refresh and reconnect, validation, failure handling.
Who has to approve it
The person whose calendar decides your go-live date.
A workspace owner, on a Business, Enterprise or Edu plan. Connectors are not a personal-account feature.
Identity and OAuth model
Whose identity the product acts as, and where that grant lives.
A token Meetext issues for this environment alone, separate from the same customer's Claude connector.
What Meetext owns
The repeatable half, turned into software.
The hosted MCP endpoint, the per-customer token, the frozen package behind it, and revocation.
What the customer owns
The half that is theirs and should stay theirs.
Their ChatGPT workspace, and who inside it can use the connector.
Capability and permission model
How capabilities map onto what the platform will let you do.
Not provider scopes. The token reaches this customer's entitlement at their approved version.
Validation
What has to execute before anyone is told it works.
Proven by connecting, not by being configured. Nothing is marked connected until a request arrives.
Credential lifecycle
Rotation, expiry, revocation, and who notices first.
One token per environment, rotatable, and independent of every other destination this customer runs.
Deployment versioning
What happens to this customer when you ship version four.
Per customer, not per server. A new vendor version does not move an installed customer.
Typical failure modes
What actually goes wrong, named rather than generalised.
A non-public endpoint, refused at publish. Beyond that, a workspace on a plan without connector support, which is the customer's to resolve.
Operational monitoring
How you learn it broke without the customer telling you.
Token issued, endpoint publicly reachable, and whether the client has ever connected.
Common questions
- Does Meetext support ChatGPT?
- ChatGPT support is in preview. The adapter is complete and every path is covered by tests against a provider simulator, which proves our logic and not the provider's. Not yet exercised with real provider credentials: authorization, installation, execution, refresh and reconnect, validation, failure handling. Meetext does not yet operate production ChatGPT customer deployments.
- Who has to approve a ChatGPT installation?
- A workspace owner, on a Business, Enterprise or Edu plan. Connectors are not a personal-account feature.
- What goes wrong with ChatGPT deployments?
- A non-public endpoint, refused at publish. Beyond that, a workspace on a plan without connector support, which is the customer's to resolve.
Current support status
PreviewChatGPT
The adapter is real and something is incomplete, either a part of the destination or real-provider proof for part of the lifecycle. The gap is stated on the page rather than discovered during an evaluation.
The adapter is complete and every path is covered by tests against a provider simulator, which proves our logic and not the provider's. Not yet exercised with real provider credentials: authorization, installation, execution, refresh and reconnect, validation, failure handling.
- Implementation
- A complete adapter.
- Proof
- Covered end to end against a provider simulator. Never run against the real provider.
Lifecycle coverage
- authorization · simulated
- execution · simulated
- failure handling · simulated
- installation · simulated
- refresh and reconnect · simulated
- validation · simulated
This label is generated from a proof registry in the deployment code, not written on this page. Available requires a complete adapter and either dated real-provider evidence or an explicit owner attestation after simulator-complete testing. The proof row above keeps those foundations apart.
2 environments free
Stop assigning an engineer to every customer.
Connect a source, publish, and send one link. Your next enterprise customer installs itself.
2 customer environments free, forever. No card required.