Mattermost slash command response types and version-aware deferred replies

Problem: Slash command response visibility and timing

\n

When a user runs a slash command in Mattermost, the platform expects a JSON response within a few seconds. The response_type field determines who sees the result, and the Mattermost server version dictates whether deferred responses via response_url are supported.

\n

Response types in scope

\n

Mattermost supports three response_type values: in_channel broadcasts the message to everyone in the channel, ephemeral limits visibility to the invoking user, and dialog opens a modal for additional input. Choosing the right type depends on whether the result is relevant to the whole team or sensitive to the individual.

\n

Version-aware deferred responses

\n

Starting with Mattermost v6.0, the payload includes a response_url field that allows the responding service to post a follow-up message after the initial timeout. Older versions ignore this field, so deferred replies silently fail. Verifying the server version before relying on this pattern prevents surprise outages.

\n

\n
1. Log in as System Administrator, navigate to System Console Integrations Slash Commands, add a new command with a trigger word, request URL, and POST method.
\n
2. Deploy a simple HTTPS service that logs the POST body and returns a JSON object with response_type and text.
\n
3. In Mattermost, type the trigger word and observe whether the reply appears in the channel or only to you, depending on the response_type you configured.
\n
4. Check the endpoint logs to confirm the POST contains team_id, user_id, channel_id, and any trailing text.
\n

\n

Practical verification steps

\n

After registering the command, type /yourcommand test in a channel. If the reply is visible to all, response_type is in_channel; if it appears only to you, it is ephemeral. To test the deferred path on v6.0+, include response_url in the initial return and later POST to that URL; on older servers, this step will have no effect.

\n

Risks and limitations

\n

Mattermost expects a response within approximately two seconds. Calls to external APIs that exceed this window should either respond with an ephemeral processing message and use response_url for the final result, or cache results locally. Misconfigured TLS or firewalls that block the endpoint from the Mattermost host will cause the command to appear failed without clear error text.