![I tried the new Slack API methods [Verification and CI edition]](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-b803788be81ed4dff8256a1a01d1f2c2/dbdb94b4897959aa969f4bcc4a9330db/slack-eyecatch.jpg?w=3840&fm=webp)
I tried the new Slack API methods [Verification and CI edition]
This page has been translated by machine translation. View original
Since 2026, new blocks have been added one after another to Slack's Block Kit. In this series, we introduce these new blocks and related APIs while actually trying them out.
- Part 1: Data Edition
- Part 2: General Display Edition
- Part 3: Agent Edition
- Part 4: Streaming Edition
- Part 5: Validation & CI Edition (this article)
As the final installment, we will introduce the blocks.validate method for validating Block Kit payloads.
Until now, the standard approach for validating Block Kit JSON was to paste it into the Block Kit Builder and visually inspect it. While this method is convenient, pasting them one by one becomes tedious as the number of payloads increases, and automated checks in CI are not possible.
blocks.validate provides this schema validation as an API, which makes it possible to incorporate Block Kit validation into CI. As we have seen throughout this series, new blocks come with increasing constraints—such as caption being required or labels needing to match categories—so being able to mechanically validate them before posting is very useful.
For validation, we will use the Slack CLI's slack api command, just like last time. Please refer to the following article for details on this command.
Overview of blocks.validate
| Item | Details |
|---|---|
| Endpoint | POST https://slack.com/api/blocks.validate[1] |
| Arguments | Pass exactly one of blocks / view / message |
| Required scopes | None. Can be called without an authentication token |
Pass a block array to blocks, a view such as a modal to view, and the entire message payload to message.
The important point is that it can be called without an authentication token. Since it only validates the provided JSON against the schema, no authentication is required.
If validation fails, information about the invalid parts is returned in the errors array of the response.
| Item | Details |
|---|---|
pointer |
JSON pointer indicating the invalid location |
code |
Error code |
message |
Description of the error |
constraint |
Details of the violated constraint |
Validating a Payload
First, let's try with a valid payload.
$ slack api blocks.validate --no-auth blocks='[{"type":"section","text":{"type":"mrkdwn","text":"Hello"}}]'
{
"ok": true
}
Next, let's check for errors. The data table block introduced in Part 1 required a caption, so let's validate a payload that deliberately omits it.
$ slack api blocks.validate --no-auth blocks='[
{
"type": "data_table",
"rows": [
[ { "type": "raw_text", "text": "Week" } ],
[ { "type": "raw_text", "text": "Week of 6/29" } ]
]
}
]'
{
"ok": false,
"error": "invalid_blocks",
"errors": [
{
"code": "missing_field",
"message": "missing required field: caption",
"field": "caption",
"pointer": "/0"
}
]
}
The /0 in pointer refers to the 0th block in the passed blocks array, and the response indicates that the caption field is missing from that block.
In this way, since pointer returns which field in which block is violating a constraint, you can immediately identify the location to fix even in messages with many blocks.
Incorporating into CI
Let's set up a GitHub Actions workflow that validates Block Kit JSON files on every pull request.
As a prerequisite, we assume a configuration where payloads used for notifications and reports are stored as JSON files in the blocks/ directory. For simplicity, we call the API directly using curl here.
Note that sending via JSON body assumes passing a token in the Authorization header, so when calling without authentication, you need to use form format.
name: validate-block-kit
on:
pull_request:
paths:
- 'blocks/**.json'
- '.github/workflows/validate-block-kit.yml'
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Validate Block Kit payloads
run: |
status=0
shopt -s nullglob
files=(blocks/*.json)
if [ ${#files[@]} -eq 0 ]; then
echo "No blocks/*.json files found"
exit 1
fi
for f in "${files[@]}"; do
res=$(curl -s -X POST https://slack.com/api/blocks.validate \
--data-urlencode "blocks@$f")
if [ "$(printf '%s' "$res" | jq -r '.ok')" = "true" ]; then
echo "OK: $f"
else
echo "NG: $f"
printf '%s' "$res" | jq .
status=1
fi
done
exit $status
If any files fail validation, the response is output to the log and the job is marked as failed.
This makes it possible to detect mistakes such as missing required fields or character limit overflows in blocks at the pull request stage.
Summary
In this article, we introduced the blocks.validate method for validating Block Kit payloads and an example of incorporating it into CI.
This is the final installment of the series. Over five articles, from the Data Edition to the Validation & CI Edition, we have introduced Block Kit's new blocks and related APIs.
We hope you got a sense of the trend in which Block Kit is taking on an increasingly wide range of responsibilities—data display, agent responses, streaming, and more—and is rapidly evolving toward agent-oriented use cases.
Thank you for reading to the end!