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.
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.
What a forward deployed engineer does by hand today.
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.
The person whose calendar decides your go-live date.
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.
Whose identity the product acts as, and where that grant lives.
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.
The repeatable half, turned into software.
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.
The half that is theirs and should stay theirs.
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.
How capabilities map onto what the platform will let you do.
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.
What has to execute before anyone is told it works.
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.
Rotation, expiry, revocation, and who notices first.
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.
What happens to this customer when you ship version four.
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.
What actually goes wrong, named rather than generalised.
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.
How you learn it broke without the customer telling you.
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.
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.
Lifecycle coverage
This label is generated from a proof registry in the deployment code, not written on this page. A destination cannot read Available until every lifecycle path above has actually run against the real provider, and a test refuses the claim without dated evidence.
Connect a source, publish, and send one link. Your next enterprise customer installs itself.
2 customer environments free, forever. No card required.
