Meetext documentation

Meetext is the infrastructure between your product and every enterprise customer who wants it inside their own workspace. You connect one source. Each customer installs once. Meetext validates and watches every one of those installations.

What Meetext models

The unit Meetext owns is the customer deployment. Not a workflow, not an integration, not a connector listing. One named enterprise customer, running one version of your product, inside one destination they control, with credentials that belong only to them.

That framing decides everything else in these pages. Capabilities are approved once and frozen into a package so a customer's installation cannot change underneath them. Health is answered per deployment rather than per service. Credentials are scoped to a single customer environment by the shape of their name, not by a policy someone has to remember.

The work this replaces is a forward deployed engineer joining a call for every new customer: reading their workspace, choosing what to expose, wiring the credentials, and being the person who finds out it broke. Meetext does that work once and then repeats it.

Vocabulary

These seven words appear on every page. They are worth two minutes.

Product: Your software as Meetext represents it: a name, a slug, one or more sources, a set of approved capabilities, and the destinations it can ship into.
Source: Where capabilities are discovered from. An MCP server, an OpenAPI document, or a repository. See Sources.
Capability: One operation your product exposes, with a name, a JSON Schema for its arguments, and a risk level of read, write or destructive. See Capabilities.
Customer: An enterprise buying your product. A customer has a slug and one installation link.
Customer environment: One customer, one product, one destination. It holds that customer's credentials and their own bearer token for the hosted MCP endpoint. This is also the unit your plan counts.
Deployment: A specific installation of a published package into a customer environment, carrying its own state and health. See Deployments.
Destination: Where the customer actually uses your product. Slack and Microsoft 365 ship today. See Integrations.

Documentation sections

If you are evaluating Meetext, read the quickstart and then the security model. If you are already building, the reference pages are the ones that stay open.

QuickstartConnect a source, approve capabilities, create a customer, send an install link, and watch the deployment validate.SourcesMCP servers, OpenAPI documents and repositories: what gets imported, what gets refused, and why the refusals are shown to you.CapabilitiesDeterministic risk classification, the deliberate second approval for writes, and re-approval when a source changes shape.DeploymentsThe nine deployment states, the three health layers and why they stay separate, incidents, and dependency degradation.Hosted MCP endpointPOST /mcp/products/{slug}, one bearer token per customer environment, three protocol versions, four methods.Security modelSchema validation before your backend is reached, auditing by argument name, credential scoping, and the shareable security review.REST APIThe resource surface, API keys, authentication, errors and idempotency.

The lifecycle end to end

Everything in these docs sits somewhere on this sequence. The left column is who acts.

Actor	Step	Result
You	Connect a source	Meetext introspects it and lists every operation, including the ones it refused to import and why.
You	Select and approve capabilities	Read capabilities are approved as you select them. Write and destructive ones need a second, explicit approval.
You	Publish	The approved set is frozen into a deployment package with a version. Customers install a package, never a live list.
You	Create a customer and send one link	A hosted installation portal at /deploy/{organization}/{customer}, reached with a single use token.
Customer	Authorize in their own workspace	Their admin grants the app in whichever destination this environment targets. The credentials that come back are stored under a name scoped to that one environment.
Meetext	Validate	Real calls: authenticate, compare granted scopes against what the capabilities need, round trip the hosted MCP endpoint, execute a read capability end to end.
Meetext	Monitor	Continuous checks, token refresh before expiry, incidents when something changes, and a state transition you are notified about.

Conventions in these docs

https://api.meetext.xyz is the REST API base. https://mcp.meetext.xyz serves the hosted MCP endpoint. Both are configurable for self hosted installations.
Path parameters appear as {product_id}. Anything in $UPPER_CASE is a shell variable you supply.
Every example authenticates with an API key in an authorization: Bearer header. Customer facing calls to the MCP endpoint use a different token entirely, issued per customer environment.
Where a page states a rule that the backend enforces, it names the behaviour rather than the intention. If it says a call is refused, it is refused in code and covered by a test.