---
title: "Slack Interactions"
method: POST
path: "/v1/webhooks/slack/interactions"
tags: ["webhooks"]
---

# Slack Interactions

`POST /v1/webhooks/slack/interactions`

## Request

- Base URL: `https://api.patricia.app` (the document declares no server; this is the origin it was published from)
- URL: `https://api.patricia.app/v1/webhooks/slack/interactions`
- Auth: none declared

Verify + ACK (<3s); enqueue an approval resume for button clicks.

Four answer shapes, because Slack reads them differently. A ``block_actions`` click is happy
with any 2xx and keeps the ``{"ok": true}`` body it has always had. A ``view_submission`` is
not: Slack closes the modal only on a 200 with an EMPTY body, and treats a JSON body as a
``response_action`` instruction, and ``{"ok": true}`` names none, so the modal would sit there
looking broken. A submission the service could not carry out answers with a real
``response_action`` — without one the modal closes as though it had worked. And a
``block_suggestion`` type-ahead request wants neither: it must get its ``{"options": [...]}``
body back, on every keystroke, or the field simply shows nothing.

The service decides all four and this route only relays them, INCLUDING the body: composing a
``response_action`` or an options list here would put user-facing copy in a transport.

allow-long-function: one four-way relay over the answer shapes documented above; splitting it
would separate a branch from the Slack behavior it exists to match.

## Response `200`

Successful Response

- unknown

---

[API](https://skmtc.dev/patricia/apis/patricia-api.md) · [All operations](https://skmtc.dev/patricia/apis/patricia-api/llms.txt) · [OpenAPI document](https://skmtc.dev/patricia/apis/patricia-api/revisions/0dfb44495ea1?raw)