Quickstart

Before you start

You need three things.

• An API key. Create one in the dashboard under Settings, or with POST /v1/auth/api-keys. The plaintext key is returned once and never again.
• A source. A reachable MCP server, an OpenAPI document, or a repository Meetext can scan. Any one of the three is enough.
• A destination app. Whichever destination you are targeting credentials for your own app registration, configured on the product's target. Your customers authorize your app, not ours.

export MEETEXT_API_KEY="mtx_live_..."
export MEETEXT_API="https://api.meetext.xyz"

1. Create a product

A product is your software as Meetext represents it. The slug is permanent: it becomes part of the hosted MCP endpoint URL that customers point their clients at.

curl -X POST "$MEETEXT_API/v1/products" \
  -H "authorization: Bearer $MEETEXT_API_KEY" \
  -H "content-type: application/json" \
  -d '{"name": "Acme AI", "slug": "acme-ai"}'

2. Connect a source

Connecting a source runs discovery. Meetext introspects the surface, normalizes every operation it accepts into one internal capability format, and records every operation it refused along with the reason.

curl -X POST "$MEETEXT_API/v1/products/$PRODUCT_ID/sources" \
  -H "authorization: Bearer $MEETEXT_API_KEY" \
  -H "content-type: application/json" \
  -d '{
    "type": "mcp",
    "mcp": {
      "url": "https://acme.example.com/mcp",
      "auth_scheme": "Bearer",
      "auth_token": "'"$ACME_TOKEN"'"
    },
    "discover_now": true
  }'

Pass discover_now: true to run discovery inline and get the capability list back in the same response. Leave it out and discovery is queued, which is the right choice for a repository scan.

The credential you send is written straight to Secret Manager. The source row keeps only the secret name.

3. Approve capabilities

List what was discovered, then decide. Every capability arrives with a risk level derived by rules: read, write or destructive.

curl "$MEETEXT_API/v1/products/$PRODUCT_ID/capabilities" \
  -H "authorization: Bearer $MEETEXT_API_KEY"

# Selecting a capability is one call.
curl -X POST \
  "$MEETEXT_API/v1/products/$PRODUCT_ID/capabilities/$CAP_ID/selection" \
  -H "authorization: Bearer $MEETEXT_API_KEY" \
  -H "content-type: application/json" \
  -d '{"enabled": true}'

# A write or destructive capability needs a second, explicit approval.
curl -X POST \
  "$MEETEXT_API/v1/products/$PRODUCT_ID/capabilities/$CAP_ID/approval" \
  -H "authorization: Bearer $MEETEXT_API_KEY" \
  -H "content-type: application/json" \
  -d '{"approved": true}'

Selecting a read capability approves it. The second call exists so that exposing something which mutates a customer's data is never a side effect of a checkbox. See Capabilities for the classification rules.

4. Publish

Preflight first. It reports anything that would make an installation fail: no destination configured, no approved capability, missing destination credentials.

curl "$MEETEXT_API/v1/products/$PRODUCT_ID/preflight" \
  -H "authorization: Bearer $MEETEXT_API_KEY"

curl -X POST "$MEETEXT_API/v1/products/$PRODUCT_ID/publish" \
  -H "authorization: Bearer $MEETEXT_API_KEY"

Publishing is what makes a change reach customers. Until you publish, approving a new capability changes nothing for anyone already installed.

5. Create a customer

A customer is the enterprise. A customer environment is that enterprise plus one product plus one destination, and it is the unit your plan counts.

curl -X POST "$MEETEXT_API/v1/customers" \
  -H "authorization: Bearer $MEETEXT_API_KEY" \
  -H "content-type: application/json" \
  -d '{"name": "Nike", "slug": "nike"}'

curl -X POST "$MEETEXT_API/v1/customers/$CUSTOMER_ID/environments" \
  -H "authorization: Bearer $MEETEXT_API_KEY" \
  -H "content-type: application/json" \
  -d '{"product_id": "'"$PRODUCT_ID"'", "target_kind": "slack"}'

6. Send the installation link

The environment response carries the portal URL and its single use token. That link is the entire handover.

https://meetext.xyz/deploy/acme/nike?t=<portal_token>

The person who opens it is not a Meetext user and never becomes one. They see what your product will be able to do, in their own vocabulary, with each capability's risk level shown, and one button that starts the authorization in their workspace.

7. Watch it validate

Authorization completing is not success. When the customer returns from the destination, Meetext runs the validation suite: it authenticates with the new credential, compares the granted scopes against what the approved capabilities need, confirms the installation identity the destination reported is actually present, round trips its own MCP endpoint with this environment's token, lists tools, and executes a read only capability end to end.

curl -X POST "$MEETEXT_API/v1/deployments/$DEPLOYMENT_ID/validate" \
  -H "authorization: Bearer $MEETEXT_API_KEY"

curl "$MEETEXT_API/v1/deployments/$DEPLOYMENT_ID" \
  -H "authorization: Bearer $MEETEXT_API_KEY"

Only when those observations hold does the deployment become healthy. A failure lands you in a state that names who has to act: authorization_required for a missing scope, degraded when a dependency is down, failed when the deployment itself cannot work. See Deployments.

8. Make a real call

The customer environment has its own bearer token for the hosted MCP endpoint. Fetch it once and hand it to whichever client the customer uses.

curl "$MEETEXT_API/v1/environments/$ENV_ID/mcp-token" \
  -H "authorization: Bearer $MEETEXT_API_KEY"

curl -X POST "https://mcp.meetext.xyz/mcp/products/acme-ai" \
  -H "authorization: Bearer $MCP_TOKEN" \
  -H "content-type: application/json" \
  -H "accept: application/json, text/event-stream" \
  -d '{"jsonrpc": "2.0", "id": 1, "method": "tools/list"}'

The tools that come back are the ones in this environment's deployment package, not the live capability list. A source that changes shape tomorrow cannot change what this customer sees until you publish again.

Where to go next

• Sources for what each source type imports and refuses.
• Hosted MCP endpoint for the protocol surface your customers' clients speak.
• Security model for the page your customer's security team will ask for.