IntegrationsSlack
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.
Your AI, MCP server or API
Their workspace and approved access
Their entitled capabilities and version
Validation, health and the next action
Available today
Ready for customer deployments with customer-scoped authorization, validation and lifecycle management.
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.
Ready for customer deployments with customer-scoped authorization, validation and lifecycle management.
Available for customer deployments, with customer-scoped authorization, validation and lifecycle management.
Connect a source, approve what ships and send your customer an install link. 2 customer environments free. No card required.
