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 on their installation page and adds a custom connector in Claude.
IntegrationsClaude
Claude
Every other destination is somewhere Meetext installs into. Claude is the opposite: it connects inward, over the public internet, to an endpoint that already exists. What makes it a deployment is not the protocol but everything around it.
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 or administrator, since a connector is available to the people they choose.
Identity and OAuth model
Whose identity the product acts as, and where that grant lives.
A token Meetext issues for this environment alone. There is no third-party grant, because there is no third party.
What Meetext owns
The repeatable half, turned into software.
The hosted MCP endpoint, the per-customer token, the frozen package that decides which capabilities that token can reach, and revocation.
What the customer owns
The half that is theirs and should stay theirs.
Their Claude 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 exactly the capabilities this customer is entitled to at the version approved for them, and nothing else the vendor has published.
Validation
What has to execute before anyone is told it works.
The connector proves itself by connecting. A request arriving with this environment's token is the only evidence anybody finished the setup, so nothing is marked connected before it happens.
Credential lifecycle
Rotation, expiry, revocation, and who notices first.
One token per environment, rotatable. Rotating it disconnects this customer's connector and no other.
Deployment versioning
What happens to this customer when you ship version four.
Nike stays on the package approved for Nike when the vendor publishes a new version. A hosting platform has one server at one version; this is one customer's installation of it.
Typical failure modes
What actually goes wrong, named rather than generalised.
An endpoint that is not publicly reachable, which fails silently: the customer pastes it, Claude reports a connection error, and nothing on this side hears about it. Refused at publish rather than discovered later.
Operational monitoring
How you learn it broke without the customer telling you.
Whether the token is issued and the endpoint is a public address Claude could reach, plus whether it has ever actually connected.
Common questions
- Does Meetext support Claude?
- Claude 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 Claude customer deployments.
- Who has to approve a Claude installation?
- A workspace owner or administrator, since a connector is available to the people they choose.
- What goes wrong with Claude deployments?
- An endpoint that is not publicly reachable, which fails silently: the customer pastes it, Claude reports a connection error, and nothing on this side hears about it. Refused at publish rather than discovered later.
Current support status
PreviewClaude
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.