A useful Slack button connects the conversation to the next step in your system. An approval can update a record, an acknowledgement can assign an owner, and a modal can collect the detail needed to finish the work.

There are two distinct ways to connect this to Make: handle Slack’s raw interactions yourself, or let LithoBlocks receive the Slack interaction and dispatch a configured webhook to your scenario.

The LithoBlocks path

This walkthrough uses Make’s generic HTTP and webhook modules. The native LithoBlocks custom app is available to invited preview testers; a public marketplace release is not required for this flow.

  1. Create the message template. Add a button such as “Approve” and include an identifier in its configured value so the action can be associated with the right request.
  2. Create a Make webhook. In a scenario, use Webhooks → Custom webhook and copy the receiver URL.
  3. Add a destination in LithoBlocks. Open Webhooks, create a destination using that URL, select POST and configure the JSON payload. Keep authentication appropriate to your receiver.
  4. Connect the button. In the template’s action configuration, add a webhook action and select the destination.
  5. Send the template from Make. Use an HTTP request to the LithoBlocks template-send API with a real template UUID, one destination and your data. Keep the bearer key in Make’s credential configuration.
  6. Inspect a controlled interaction. Click a button on a test message, confirm the receiver got the intended fields, and inspect the interaction and webhook logs.

For example, a configured webhook payload can include:

{
  "action": "approve",
  "request_id": "{{interaction.action_value}}",
  "approved_by": "{{user.id}}",
  "timestamp": "{{system.timestamp}}"
}

Use context.* for original send data. The payload your scenario receives is the JSON you configure; do not apply raw Slack payload parsing to it. See button webhooks and the variable reference.

Update the message after the action

Configure a message update so the original request reflects the outcome. If you need a comment or another field first, open a bound modal and configure the submission workflow. Your team can then see the result in the original conversation.

Decide what an update means: “request received” is different from “approved in the downstream system.” Do not show a completed state solely because an HTTP request was dispatched. Inspect webhook results and design your downstream processing to handle duplicates safely.

Explore message updates · Choose a modal or a message

If you handle Slack directly

With your own Slack app, Slack posts a form-encoded body containing a JSON payload field to your interactivity URL. Route using the interaction’s action ID and respond within Slack’s three-second acknowledgement window. A long Make scenario must not delay that acknowledgement.

Verify the actual response behavior of your Make webhook setup. If your receiver uses Slack’s response_url, follow its current lifetime and response limits. Also verify Slack request signatures at the receiving boundary; knowing a webhook URL is not proof that Slack sent a request. Slack’s interaction guide describes the full contract.

This direct path is separate from a LithoBlocks destination. Keep the setup and payload formats distinct.

What uses credits?

The initial direct template send uses 1 credit. The button callback and message update do not add a message credit. A separately triggered send or standalone compile does. See credit examples.

Explore the workflows · Make integration guide