# Meetext, in full > Forward deployed engineering should scale like software. Meetext is the forward deployed engineering layer between software companies and the enterprises they sell to. A software company connects its product once, as an MCP server, an OpenAPI document or a repository. Meetext then handles the work that currently falls to a forward deployed engineer for every enterprise customer: deployment packaging, entitlements, the authorization lifecycle, security review, validation, credential management, health, incident handling, versioning and rollback, and the operational record of all of it. The unit Meetext owns is the customer deployment. Not the integration, not the connector, not the workflow: one customer, one product, one destination, with its own version, state, credentials and history. What Meetext is not: - Not an MCP host. Hosting a protocol endpoint is the smallest part of the problem. - Not an automation builder. It does not wire your applications to each other; it installs your product into somebody else's company. - Not a unified API. It does not abstract over other people's products. - Not an implementation consultancy. There is nobody to schedule, and software priced per environment gets better when deployment is faster, where a consultancy gets worse. The arc, stated in order because each stage needs the one before it: 1. Deployment infrastructure. Running today. 2. Deployment intelligence, as the operational record accumulates. Partly built: incidents are fingerprinted, correlated with what changed, and resolutions record whether causality is even attributable. 3. The software forward deployed engineer, operating on top of that record. Not shipping, and not claimed. ## AI in customer workspaces Meetext carries a software vendor's own AI assistant into their customers' workspaces. A customer's employee asks a question in Slack, Microsoft Teams or Google Chat. Meetext resolves which customer that workspace belongs to, sends the question to an endpoint the vendor runs, and relays the reply into the same thread. What is the vendor's: the model, the prompt, any tools they add on their own side, and the name the bot answers under. Nothing identifies Meetext to the person asking. What Meetext adds is the part that is the same for every customer: - Resolving a workspace to exactly one customer installation. An unknown workspace is ignored, and so is an ambiguous one, because answering there would mean answering one customer's question against another customer's data. - Handing the assistant that customer's own MCP endpoint and bearer token, so it can act inside their workspace with their credentials, bounded by the deployment package frozen at their install and by what they are entitled to. - Relaying a streamed answer as it arrives. The reply is posted on the first chunk and the same message is edited as it grows, rather than posting fragments or waiting in silence. A single non-streamed reply works without the vendor changing anything. - Handling failure so somebody is never left waiting. An answer that fails partway keeps what arrived and appends the reason. The vendor's own error text goes to their event log and never into their customer's channel. Conversation history is neither sent to the vendor nor stored by Meetext. A stable thread reference is sent instead and the vendor's assistant keeps its own memory against it. A vendor who has not built an assistant can use a model Meetext runs. It is given the same per-customer endpoint as its tools, so it answers only from capabilities the vendor approved and that customer bought, rather than from general knowledge about their business. Status: the bridge is complete and covered end to end against a provider simulator, and can be exercised locally against a stand-in assistant. It has not yet carried a question in a real Slack workspace, Teams tenant or Google Chat space, which is the same reason no destination on this site reads Available. Page: https://meetext.xyz/ai-in-customer-workspaces ## How support status is decided Meetext publishes support status derived from four separate facts that are deliberately never collapsed: - implementation: does an adapter exist, and is it complete - synthetic proof: does it pass against a provider simulator - real provider proof: have real credentials gone through it - production paths: which parts of the deployment lifecycle were exercised for real A destination is only described as "available" when a complete adapter has been run against the real provider across every production path, with dated evidence recorded by a named person. Nothing has earned that yet. All seven destinations are "preview": the adapters are complete and covered end to end against simulators, and none has run against a real provider account. This is enforced by tests, not by policy. A destination cannot be advertised as available without the evidence, and a test fails if the published catalog disagrees with the code. ## Destinations Where a vendor's product is installed. Each entry states its real status, then answers the same eleven questions, so two destinations can be compared on the same terms. ### Atlassian Status: preview. The adapter ships with a named gap. Not yet exercised with real provider credentials: authorization, installation, execution, refresh and reconnect, validation, failure handling. Jira and Confluence Cloud ship. Data Center is declared by the adapter and refused at deploy time: it is the customer's own infrastructure on their own upgrade schedule, which is a different adapter rather than a setting. Limit: Jira and Confluence Cloud ship. Data Center is declared by the adapter and refused at deploy time: it is the customer's own infrastructure on their own upgrade schedule, which is a different adapter rather than a setting. Atlassian is two deployment stories wearing one brand. Cloud apps go through Forge or Connect and the Marketplace; Data Center apps are installed by an administrator into infrastructure the customer runs. A page that says "we integrate with Jira" has not said anything. **How installation normally works.** Cloud: a Forge or Connect app, installed by a site administrator, usually via the Marketplace. Data Center: a plugin installed into the customer's own instance, on their upgrade schedule. **Who has to approve it.** A Jira or Confluence site administrator. In Data Center, whoever owns the servers, which is frequently a different team with a different change process. **Identity and OAuth model.** OAuth 2.0 (3LO) for cloud, with app-scoped tokens for Forge. Data Center authentication is whatever the customer's instance is configured for, which may be SAML, may be LDAP, and is not something the vendor controls. **What Meetext owns.** The Cloud OAuth 3LO flow, resolving the cloud id that every API call needs and which is only discoverable after authorization, and validation that reads a real project. Data Center is declared and refused at deploy time rather than treated as Cloud, because a wrong assumption there fails inside your customer's own datacentre. **What the customer owns.** The site or the instance, project permissions, and the Marketplace approval if their policy requires one. **Capability and permission model.** Scopes for cloud, plus per-project permission schemes that can make a granted scope useless on the project that matters. **Validation.** Reading a project the customer actually uses, not the sample project, because permission schemes differ per project. **Credential lifecycle.** Rotating OAuth tokens on cloud. Data Center credentials live in the customer's instance. **Deployment versioning.** Marketplace app versions and per-site installed versions are separate, and Data Center customers upgrade on their own schedule, sometimes years apart. **Typical failure modes.** A scope granted at site level and a project permission scheme that denies it anyway. Cloud and Data Center behaviour differing under identical configuration. Rate limits on large instances. **Operational monitoring.** Health compares the scopes this installation holds against what the current package needs. HubSpot does not extend existing installs when an app adds a scope, so an older customer shows as needing a reinstall instead of the capability silently failing for them. Page: https://meetext.xyz/integrations/atlassian ### Google Workspace Status: preview. The adapter ships with a named gap. Not yet exercised with real provider credentials: authorization, installation, execution, refresh and reconnect, validation, failure handling. Google Chat ships. The Docs and Gmail add-on, Drive and Gemini surfaces are declared by the adapter and refused at deploy time rather than failing later. Limit: Google Chat ships. The Docs and Gmail add-on, Drive and Gemini surfaces are declared by the adapter and refused at deploy time rather than failing later. Google Workspace is not one destination. Chat apps, Docs and Gmail add-ons, Drive integrations and Gemini extensions have different manifests, different reviews and different failure modes. An adapter that treats "Google" as one thing cannot tell you what it actually installed. **How installation normally works.** The vendor configures a Chat app in a Google Cloud project, publishes it to their domain or to the Marketplace, and the customer installs it into their own Workspace domain. Marketplace review is a separate calendar. **Who has to approve it.** A Workspace super admin for domain-wide installation, or an individual user for a personal install. Meetext reports a personal Google account rather than silently accepting it, because a deployment that works for one person is not a deployment. **Identity and OAuth model.** Ordinary three-legged OAuth against the installing user. Domain-wide delegation is deliberately not used: it would let Meetext act as any user in the customer's domain, which is more access than any capability needs and the single hardest thing to get through a security review. **What Meetext owns.** The Chat surface end to end, recording the Workspace domain so two customers are never confused, and refusing surfaces that are declared but not implemented rather than quietly behaving like Chat. **What the customer owns.** Domain installation and the admin console policies around it. Uninstalling revokes the grant at Google, not just Meetext's copy of it. **Capability and permission model.** Chat scopes only. A capability that would need Drive or Gmail access is refused at deploy time, because an installation that quietly targets the wrong surface is worse than one that will not start. **Validation.** Authentication, domain identification, capability listing and a real execution, the same as everywhere else. The Workspace domain is part of what gets validated, not an assumption. **Credential lifecycle.** Google refresh tokens, held per environment. Revocation at Google disconnects the environment and asks the customer to reinstall, which is the only thing that can fix it. **Deployment versioning.** Frozen package per customer, as everywhere. Marketplace listing versions are a separate axis and are the vendor's to manage. **Typical failure modes.** A personal Gmail account used where a Workspace domain was expected. A surface that is not Chat, which is refused rather than attempted. Marketplace review delays, which are nobody's fault and still your go-live date. **Operational monitoring.** The same three layers, with the Workspace domain recorded on the environment so an incident names which customer domain it belongs to. Page: https://meetext.xyz/integrations/google-workspace ### HubSpot Status: 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. HubSpot is comparatively simple, which makes it a good early test of whether the destination model generalises without special cases. **How installation normally works.** A public app installed into the customer's portal through an OAuth install link, or a private app for a single portal. **Who has to approve it.** A HubSpot super admin, or a user with app installation permission. **Identity and OAuth model.** OAuth 2.0 per portal, with refresh tokens and portal-scoped access. **What Meetext owns.** The public app OAuth flow, resolving the portal id by introspecting the token because it is not in the token response, reading the scopes the install actually holds rather than the ones we asked for, and per-portal credential storage. **What the customer owns.** The portal, and which objects the app may touch. **Capability and permission model.** Granular scopes per object type. Adding a scope to a published app requires existing customers to reinstall, which is a per-customer deployment event rather than a release. **Validation.** Reading a real object in the portal after install. **Credential lifecycle.** Refresh tokens per portal, rotated before expiry. **Deployment versioning.** App versions are global; installed scopes are per portal. Those diverge the moment you add a scope. **Typical failure modes.** Scope changes requiring reinstall across the whole customer base. Portal-level API limits shared with everything else the customer runs. **Operational monitoring.** Health compares the scopes this installation holds against what the current package needs. HubSpot does not extend existing installs when an app adds a scope, so an older customer shows as needing a reinstall instead of the capability silently failing for them. Page: https://meetext.xyz/integrations/hubspot ### Microsoft 365 Status: 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. Microsoft is where the difference between user consent and admin consent stops being a detail. AADSTS90094 and AADSTS90093 mean different things, and only one of them is something the person in front of you can fix. Getting that wrong turns a two-hour install into a three-week escalation. **How installation normally works.** The vendor registers an application in Entra, decides which Graph permissions the capabilities need, and sends a consent link. Whether that link works depends on the tenant's consent policy, which the vendor cannot see and the customer often cannot describe. **Who has to approve it.** A Global Administrator or Privileged Role Administrator when admin consent is required, which it is for any Graph permission on the admin-only list. Otherwise the installing user can consent for themselves, and the deployment works for exactly one person. **Identity and OAuth model.** Tenant-scoped OAuth against login.microsoftonline.com, tokens against Microsoft Graph. The tenant is recorded as a vendor-scoped pseudonym rather than as raw tenant data, so the same customer is recognisable across destinations without Meetext holding a globally stable identifier. **What Meetext owns.** Distinguishing admin consent from user consent before the customer hits it, naming the required Graph permissions and which of them an administrator must approve, running the tenant-scoped exchange, refreshing tokens before they expire, and normalising AADSTS codes into signals that mean something. **What the customer owns.** Consent, and the tenant policy that decides who can give it. Conditional Access is theirs too, and when it blocks token issuance Meetext reports that rather than guessing which policy did it. **Capability and permission model.** Graph permission names map to capability requirements. Permissions only an administrator can consent to are marked as such in the deployment package, so the security review shows them before the install rather than after it fails. **Validation.** Authentication against Graph, scope comparison against the package, capability listing, and a real execution. Admin consent required is reported as waiting on the customer's administrator, which is a state, not a failure. **Credential lifecycle.** Refresh tokens are exchanged before expiry rather than on failure. A removed scope produces a re-authorization request rather than a quiet degradation, and a revoked grant disconnects the environment and offers a reconnection link. **Deployment versioning.** Same freeze as everywhere. A new product version that needs a new Graph permission cannot silently apply to an existing customer, because the consent they gave was for a package with a different digest. **Typical failure modes.** AADSTS90094: admin consent required, which may be the tenant restricting user consent or may be a permission that always needs an admin. AADSTS90093: user consent blocked by policy. AADSTS65001: consent never granted. AADSTS53003: Conditional Access blocked issuance, and the error does not say which policy. **Operational monitoring.** Graph is watched as a named dependency. When Graph is degraded the deployment is degraded because of Microsoft, and the incident says so, so nobody spends a day debugging their own code during somebody else's outage. Page: https://meetext.xyz/integrations/microsoft-365 ### Salesforce Status: 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. Salesforce is the destination customers ask about first and the one where forward deployed engineering is most obviously a job. Every org is different: custom objects, validation rules, sharing models, profiles and permission sets built over a decade by people who have left. This is why the page below describes the problem rather than a shipping product. **How installation normally works.** A managed or unmanaged package, or a Connected App, installed into a sandbox first and then promoted to production through the customer's own change process. There is no version of this that takes an afternoon. **Who has to approve it.** A Salesforce administrator, and usually a change advisory board as well. In regulated industries the sandbox-to-production promotion is a scheduled event, not a request. **Identity and OAuth model.** OAuth 2.0 against the customer's org, with the JWT bearer flow for server-to-server. Connected App policies, IP restrictions and permitted-users settings all decide whether a grant works, and all of them are the customer's. **What Meetext owns.** The Connected App OAuth flow, with sandbox and production as separate environments, recording the org's instance url because every call must go there, per-environment credential storage, and validation that runs a real query and checks the fields came back. Field level security hides data by omitting it rather than failing, so a check that only counted rows would call a broken deployment healthy. **What the customer owns.** The org. Its objects, its sharing rules, its profiles, its change process, and the decision about what a package is allowed to read. **Capability and permission model.** Object and field level security, permission sets, sharing rules. A capability that reads an Opportunity is not one permission, it is a profile, a permission set and a sharing model that has to agree. **Validation.** Executing against a sandbox, then against production, and treating those as different environments rather than the same one twice. **Credential lifecycle.** Refresh tokens with org-level revocation. Connected App policy changes can invalidate a grant without anything failing until the next call. **Deployment versioning.** Package versions and org state are separate axes, and an upgrade can succeed while leaving the org in a configuration the new version does not expect. This is precisely the problem the deployment control plane exists to model. **Typical failure modes.** Field level security silently returning nothing rather than an error. Governor limits under load. A sandbox refresh wiping configuration. A validation rule written in 2019 rejecting a record the integration creates. **Operational monitoring.** The three layers, with the org's daily API allowance watched. That allowance is shared with everything else the customer runs, so exhausting it degrades Salesforce as a named dependency rather than reporting your product as broken. Page: https://meetext.xyz/integrations/salesforce ### ServiceNow Status: 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. ServiceNow implementations are mostly repeated configuration, rebuilt by hand per instance, promoted through update sets that drift from each other. It is the clearest example of work that looks bespoke and is not. **How installation normally works.** A scoped application or an integration built directly in the instance, developed in a sub-production instance and promoted through update sets. Nothing about this is a single install step. **Who has to approve it.** The ServiceNow platform team, and a change request through the customer's own ITSM process. Which is, with some irony, managed in ServiceNow. **Identity and OAuth model.** OAuth 2.0 against the instance, or basic auth against an integration user, which is still common and still what security review objects to. **What Meetext owns.** The instance OAuth flow, per-environment credentials, and validation that reads a real record and checks a named field survived the ACLs. ServiceNow cannot tell us which instance a grant belongs to, so it is configured before the installation starts and a missing one is caught then rather than after somebody approves something. **What the customer owns.** The instance, its update set process, its change windows, and every piece of configuration somebody added in 2018. **Capability and permission model.** Roles and ACLs. A capability needs a role that needs an ACL that may or may not exist in this instance. **Validation.** Health checks against the instance, and execution in a sub-production instance before production is touched. **Credential lifecycle.** Instance-scoped OAuth tokens, or an integration user whose password is in somebody's vault. **Deployment versioning.** Update sets are already a version mechanism and they drift. A per-customer deployment record that knows which update set is actually applied is the missing half. **Typical failure modes.** Update set collisions. Configuration present in the sub-production instance and absent in production. Platform upgrades changing behaviour under a working integration. **Operational monitoring.** Health compares the scopes this installation holds against what the current package needs. HubSpot does not extend existing installs when an app adds a scope, so an older customer shows as needing a reinstall instead of the capability silently failing for them. Page: https://meetext.xyz/integrations/servicenow ### Slack Status: 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. Slack is the easiest destination to install into and the easiest to get quietly wrong. A workspace admin can approve in a minute, which means nobody builds a process, which means nobody notices that the token belongs to a person who has since left. **How installation normally works.** Someone at the vendor creates a Slack app, works out which scopes the capabilities need, sends the customer an OAuth link, and waits. If the workspace restricts app installation, the link goes to an admin queue and nothing happens until somebody clears it. **Who has to approve it.** A workspace owner or admin, or any member if the workspace has not restricted app installs. Large enterprises almost always have restricted it, and the request lands in an approval queue that nobody is paged about. **Identity and OAuth model.** Slack OAuth v2. The grant produces a bot token scoped to one workspace, and optionally a user token acting as the installing person. Meetext stores the grant under a name scoped to a single customer environment, so no credential is ever shared between two customers. **What Meetext owns.** Generating the app manifest from your capabilities, running the OAuth exchange, storing the grant per environment, translating capabilities into slash commands within Slack's length limits, executing a real read capability to prove the install works, and watching for the revocation errors that mean the grant is gone rather than merely failing. **What the customer owns.** The decision. The consent screen names your application, lists the scopes, and says why each one is needed. Uninstalling is theirs and it takes effect at Slack, not just in Meetext's copy of it. **Capability and permission model.** Capabilities become slash commands, so a capability whose name exceeds Slack's command length limit is refused at deploy time rather than discovered missing. Read, write and destructive capabilities carry their risk into the deployment package, and destructive ones need approval before they can be published at all. **Validation.** Authentication is checked against Slack, the destination API is reached, the granted scopes are compared with the ones the package requires, capabilities are listed back through the MCP endpoint, and one real read capability is executed. A token that exists is not evidence. **Credential lifecycle.** Slack bot tokens do not expire by default, which is the problem: nothing forces the vendor to think about them until the installing user is deprovisioned and the grant silently dies. Meetext records the grant with its scopes and version, and treats Slack's revocation errors as a disconnection rather than a failure, because only the customer can fix it. **Deployment versioning.** The deployment package is frozen at install. Publishing a new product version does not move this customer until somebody moves them, so a capability you removed on Tuesday is still there for a customer who has not upgraded. **Typical failure modes.** The workspace restricts installs and the request sits in a queue. A scope was added to the product after this customer installed, so their grant no longer covers the package. The installing user leaves the company. Slack rate limits during a burst and every capability fails at once, which is not your product being broken. **Operational monitoring.** Health runs on an interval and separates the three layers: whether the MCP endpoint answers, whether the Slack grant still works, and whether capabilities actually execute. Those disagree often, and a summary that averages them describes none of the three. Page: https://meetext.xyz/integrations/slack ## Sources Where a vendor's capabilities come from. All three normalise into the same internal capability format, so every destination behaves identically. - MCP server: Streamable HTTP, protocol versions negotiated per client. - OpenAPI document: OpenAPI 3, JSON or YAML, by URL or upload. One capability per operation. - Repository: FastAPI, Flask, Django, Next.js and Express route discovery. Produces candidates a developer selects, never capabilities directly. ## Technical facts - Public API: 141 operations, OpenAPI document at /openapi.json. - MCP protocol versions supported: 2025-06-18, 2025-03-26, 2024-11-05. Transport is Streamable HTTP. - Deployment states: 9, with legal transitions between them. - Health layers, reported separately because they disagree: capability, deployment, protocol. - A failing capability returns a result with isError set, never a JSON-RPC error. The distinction decides whether a model retries. - Capability arguments are audited by name and never by value. Results transit in memory and are not stored. - Credentials live in a secret manager under a name scoped to a single customer environment, never in the database and never shared between customers. - Write and delete capabilities require a deliberate second approval, revoked if the source later changes that operation's shape. - The deployment package is frozen per customer. Publishing a new product version does not move an existing customer until somebody moves them. - Rollback targets are earlier deployments of that environment which actually reached a working state, and the rollback revalidates rather than assuming the old package still works. - Operational history is append-only and replayable. A deployment context document can be generated for any environment, carrying provenance on every inference and no secrets. ## Questions and answers Each answer is self-contained and quotable on its own. ### How do I deploy my AI assistant into my customer's Slack? You need three things and only one of them is the assistant. An app registered with Slack, Teams or Google Chat and reviewed by them; a way to turn an incoming workspace id into the right customer with the right credentials, which must never be wrong once; and per-customer access to your own product, so the assistant answers as that customer rather than as you. Meetext provides the second and third and carries the message both ways, so what you build is the assistant. Your model, your prompt and your name on the bot, with nothing identifying Meetext to the person asking. ### Can I put my own AI in my customers' workspaces without building a deployment team? That is what the assistant bridge is for. You point a product at an endpoint you run, and questions asked in a customer's Slack, Teams or Google Chat arrive there with that customer's own credentials and capabilities attached. The parts that are identical for every customer after the first, resolving whose workspace a message came from, running the consent and token lifecycle, scoping access per customer and streaming a reply back without it looking broken, are the product rather than your next quarter. ### Does Meetext see my customers' conversations? No. A question is sent to your assistant with a stable thread reference, and your assistant keeps its own memory against that reference. The history is not sent to you by Meetext and is not stored by Meetext, which is a stronger statement than a retention policy: there is nothing held to retain. Capability arguments are audited by name and never by value for the same reason. ### What stops my assistant answering one customer with another customer's data? Two things. A message is answered only when the workspace it came from resolves to exactly one installation; an unknown workspace is ignored and so is an ambiguous one, rather than being resolved by picking the first match. And the access your assistant is given is a per-customer endpoint and token, scoped to a single customer environment, so a call made for one customer cannot list or reach another's capabilities. ### What is a forward deployed engineer? An engineer who works inside a customer's environment to get a product running there: understanding their systems, configuring the integration, getting through security review, handling identity and permissions, proving it works and keeping it working. Solutions engineer, implementation engineer, customer engineer and post-sales engineer describe substantially the same job. It exists because enterprise software is sold as a product and delivered as a project, and somebody has to close that gap. ### Should I hire a forward deployed engineer? If you are asking because every enterprise customer needs weeks of engineering before they can use what they bought, a hire will solve it for the next two or three customers and then you will need another one. The work is roughly the same each time: the same OAuth flow, the same security questionnaire, the same validation, the same upgrade, against a different tenant. That part is a software problem. Hire for the judgement work, which is understanding what a customer actually needs, and make the repetition somebody else's infrastructure. ### How much does a forward deployed engineer cost? Forward deployed engineers are among the most expensive engineers to hire, because the role wants somebody who can write production code and sit in front of a customer's security team in the same week. The larger cost is usually the delay: revenue recognised months after a contract is signed, and senior engineering time spent on the fortieth repetition of a flow rather than on the product. ### What is an AI FDE? An agent that does the forward deployed engineering job: reading a customer's environment, planning a deployment, configuring it, diagnosing failures and repairing them. Nobody has finished building one. Meetext is not an AI FDE today and does not claim to be; it is the deployment control plane an AI FDE would have to operate through, because an agent reasoning over a pile of API responses will be confidently wrong, and one reasoning over an append-only deployment record with provenance on every inference can be checked. ### Is this the same as implementation consulting? No. A consultancy sells people and bills for their time, so a faster deployment is worse for them. Meetext is software priced per customer environment, so a faster deployment is the product working. There is also nobody to schedule: the repeatable parts run without a human, and the parts that still need judgement arrive with the context to make it quickly. ### How do I deploy my product into a customer's Slack, Microsoft 365 or Salesforce? Connect your product to Meetext once, as an MCP server, an OpenAPI document or a repository. Choose which operations customers should get. Meetext generates the deployment package, produces a security review artifact, and gives you one installation link per customer. The customer's administrator approves it in their own workspace, Meetext runs the OAuth flow, stores the grant scoped to that one customer, executes a real capability to prove it works, and then monitors it. ### Do I have to have an MCP server already? No. An OpenAPI document works, and so does a repository. Meetext scans FastAPI, Flask, Django, Next.js and Express for routes and service functions. Whichever you connect normalises into the same internal capability format, so every destination behaves identically. ### How long does a customer deployment take with Meetext? The parts Meetext owns take minutes: generating the package, issuing the link, running authorization, validating, and starting to monitor. What Meetext cannot compress is the customer's own calendar. If their administrator takes nine days to approve admin consent, the deployment takes nine days, and Meetext reports it as waiting on that administrator rather than as a failure or as your problem. ### What happens when my API changes? Rediscovery detects the difference and revokes approval for any capability whose contract changed, so an approved operation that quietly became a different operation cannot ship. Existing customer installations keep serving the package they were given: publishing a new version does not move an existing customer until somebody deliberately moves them. ### Can I drive all of this from CI? Yes. The dashboard is a client of the same REST API you get, every operation of it, authenticated with an API key. Create products, connect sources, approve capabilities, create customer environments and trigger validations from your own pipeline. ### Does Meetext see my customers' data? Capability results pass through the hosted endpoint in memory to reach the destination. They are not stored. Execution is audited by argument name only and never by value, so Meetext records that a search happened and not what was searched for. Credentials live in a secret manager under a name scoped to a single customer environment and are never shared between two customers. ### How do I get through my customer's security review? Meetext generates a review artifact for each customer naming the capabilities being exposed, the permission each one needs and why, where credentials live, and what data crosses which boundary. Every claim is tagged with who is standing behind it, so what Meetext observed is distinguishable from what your company asserted. Approval is recorded against the exact snapshot the customer saw, which means an approval cannot silently start covering whatever you published next. ### Whose application does the customer see on the consent screen? Yours. Each vendor registers their own Slack app, Entra application, Connected App or equivalent, and those credentials are stored per deployment target. One shared application could not represent two companies to a security reviewer, so Meetext does not try. ### Which enterprise systems can Meetext deploy into? Slack, Microsoft 365, Google Workspace, Salesforce, ServiceNow, Atlassian and HubSpot. All seven are in preview: the adapters are complete and covered end to end against provider simulators, and none has yet run against a real provider account. Meetext will not describe a destination as available until every part of the deployment lifecycle has actually run against the real provider, and a test refuses the claim without dated evidence. ### Can you add a destination that is not on the list? A destination is seven interface methods and one registry line, and contract tests run against every registered adapter so a new one is held to the same standard as the existing ones. The honest constraint is not the code, it is that each destination is a real OAuth model, permission system and set of failure modes that has to be understood before it is worth shipping. Tell us which one and how many customers, and that is how the next one gets picked. ### What counts as an active customer environment? One customer, one product, one destination. It counts while it is installed. Disconnected environments do not count, and calling your capabilities more often never changes the bill. ## Documentation - [Overview](https://meetext.xyz/docs): What Meetext models, the vocabulary the rest of the documentation uses, and where to go next. - [Quickstart](https://meetext.xyz/docs/quickstart): Connect a source, approve capabilities, create a customer, send an install link, and watch the deployment validate. - [Sources](https://meetext.xyz/docs/sources): MCP servers, OpenAPI documents and repositories: what gets imported, what gets refused, and why the refusals are shown to you. - [Capabilities](https://meetext.xyz/docs/capabilities): Deterministic risk classification, the deliberate second approval for writes, and re-approval when a source changes shape. - [Deployments](https://meetext.xyz/docs/deployments): The nine deployment states, the three health layers and why they stay separate, incidents, and dependency degradation. - [Hosted MCP endpoint](https://meetext.xyz/docs/mcp): POST /mcp/products/{slug}, one bearer token per customer environment, three protocol versions, four methods. - [Security model](https://meetext.xyz/docs/security): Schema validation before your backend is reached, auditing by argument name, credential scoping, and the shareable security review. - [REST API](https://meetext.xyz/docs/api): The resource surface, API keys, authentication, errors and idempotency. ## Releases - 23 August 2026, Your AI, in your customer's workspace: A vendor's own assistant now answers their customers' staff in Slack, Teams or Google Chat, with that customer's own credentials and capabilities. Meetext carries the question and the reply and touches nothing else. - 20 August 2026, Seven destinations, and a rule about what counts as shipped: Salesforce, ServiceNow, Atlassian and HubSpot adapters, and a proof registry that decides what the website is allowed to claim about any of them. - 16 August 2026, Firestore end to end: The store moved to Firestore completely. Every guarantee a relational schema used to give for free is now something explicit that a test proves. - 28 July 2026, Shareable security review: The artifact an enterprise security team reads before approving an installation, with every claim carrying where it came from. - 2 July 2026, Deployment timeline and attribution: Every second of a deployment's elapsed time traced to an interval, the records that created it, and the rule that attributed it. - 10 June 2026, Three health layers: Protocol, deployment and capability health separated, because they disagree and the disagreement is the useful part.