Slack trigger_id expires in 3 seconds: open the modal first

In a Slack slash command that opens a modal and starts a Sume render, open the modal before you call Sume. The trigger_id expires in 3 seconds and can be used once, so any slow work in front of it, including a Sume request, can cost you the modal. Acknowledge with a 200 within 3 seconds, and send the result later through response_url.

The Slack facts are from Handling user interaction, read 2026-10-10. The Sume facts are from Create a run and Run webhooks.

What are the Slack clocks?

The page says you must acknowledge an interaction with a 200 within 3 seconds. A trigger_id expires after 3 seconds and works only once; using it late gives trigger_expired, and using it twice gives trigger_exchanged. A response_url can be used up to 5 times within 30 minutes.

A good test is to add an artificial delay of 4 seconds in front of the modal call in a staging copy. You should see trigger_expired. If you do not, you are not testing the path that fails in production, where cold starts and slow dependencies make a 3 second budget easy to lose.

What order should the handler use?

First, take the payload and open the modal with the trigger_id. Second, return 200. Third, do the slow work outside the request, such as a queue message or a background job. When the person submits the modal, you get a new interaction with a new trigger_id and a response_url, and now you can call Sume.

A Sume request is not slow when it is async. Do not use sync mode in a Slack handler: sync waits are capped at 30 seconds, ten times the 3 second limit, and a timed out client must never become a second paid submit.

How do I submit without double billing?

Slack retries deliveries you did not acknowledge, so your handler can see the same interaction twice. Build an Idempotency-Key from the Slack payload that identifies the submission, such as the view id with a version, and send it on the Sume request. A repeat returns 200 with idempotency_hit: true and the original run.

Send communication.webhook_url so that Sume tells your server when the run is terminal, then post the media link through the saved response_url. Sume sends the event once per run.

Keep the modal itself light. Ask for the fields the Format needs, validate them locally, and submit only on the second interaction. Anything you can check without Sume, such as input length, should be checked before the paid call.

What if the render takes longer than 30 minutes?

Long Format runs can last well past the response_url lifetime. Per the Sume runs page, a run may take until its expires_at deadline, which is 90 minutes after creation. Once the 30 minutes pass, response_url is useless, and you need another way to reach the person, such as a direct message sent with your bot token.

Store the channel and user alongside the run id so the webhook handler can choose: response_url while it is still valid, a direct message after that. The 5 use limit applies too, so spend at most one reply on progress and keep the rest for the final result.