Slack Message Metadata: What Gets Stored, Dropped and Sent, Tested

Slack message metadata is a small JSON object, an event_type plus an event_payload, that an app attaches to a message it posts. People in the channel never see it. Other code reads it back through the API or receives it as a message_metadata_posted event. We tested it on 4 October 2026 with a throwaway app in a free-plan workspace, using a bot token with chat:write, channels:history and metadata.message:read, and a Socket Mode listener for the events.

Posting a message with metadata

Send metadata next to text in chat.postMessage. With a JSON body it is an object. With a form-encoded body it is a JSON string; both worked in our test:

{
  "channel": "C0C6MGP65BK",
  "text": "Order A-1042 received",
  "metadata": {
    "event_type": "sglab_order_created",
    "event_payload": {"order_id": "A-1042", "amount": 49.0, "currency": "USD", "items": 2}
  }
}

The response echoed the metadata back with one change: 49.0 came back as 49. Slack stores numbers as JSON numbers, so do not rely on a trailing .0 to mark a float.

That is everything a person sees. There is no icon, no "details" view and nothing in the message menu, even after the metadata was updated twice.

Reading it back: include_all_metadata

We read the same message with conversations.history twice, with the bot that posted it:

So without the flag you get only the type, even for metadata your own app wrote. conversations.replies behaved the same way. The logged-in web client session returned the same two shapes. A message shortcut payload is the exception: when we ran an app shortcut on the message, the message_action payload carried the full metadata, payload included, with no flag.

Bad metadata does not fail the call

Every mistake we made still returned ok: true and posted the message. Slack dropped the metadata and put a warning in response_metadata:

Upper case (Order_Created), dashes (order-created), digits, nested objects, arrays inside the payload, true and null were all accepted. The longest event_type that was kept was 100 characters. If your code only checks ok, it will never notice that the metadata is gone, so check response_metadata.warnings after every post that carries metadata.

The 4,000-byte limit, measured

We grew one string field until the metadata was dropped. The warning text gives the size Slack counted: "The size of the message's metadata is 4001 bytes. The total size of a message's metadata should not exceed 4000 bytes."

• • The whole metadata object counts, not just event_payload. Our wrapper {"event_type":"sglab_order_created","event_payload":{"blob":""}} is 64 bytes, and a 3,936-character blob (4,000 total) was kept while 3,937 was dropped.
• • Non-ASCII text counts six bytes per character. 1,400 Korean characters were counted as 8,464 bytes, which is 64 plus 1,400 times 6. Slack measures the JSON with each character escaped as \uXXXX. Keep IDs in the payload and look up long text elsewhere.

The events your app receives

Subscribing to message_metadata_posted needs metadata.message:read and a metadata subscription in the manifest that names the event type. Ours was {"app_id": "*", "event_type": "sglab_order_created"}. Then we posted, edited and deleted messages and timed the events from our call:

The updated and deleted events include previous_metadata, so you can see what changed without storing it yourself. Messages whose event_type was not in the subscription (order_created_2, order-created) sent no metadata event at all, though the plain message event still arrived. A chat.update with new text and no metadata field kept the old metadata.

For the other message events in that table, see our Slack Events API event types page and the message_changed event test.

FAQ

Can a user see or edit message metadata?

No. Nothing in Slack's web app shows it, and there is no field for it in the message menu. We changed it only through chat.update from the bot that posted the message. Reading is wider: the owner's own web session read the full payload with include_all_metadata=true, so do not put secrets in it.

Is message metadata the same as Work Objects?

No. Event metadata is the event_type and event_payload shape on this page. Work Objects use the same metadata field with an entities array instead, which is why our bad-metadata warnings listed errors for both shapes. Our Slack Work Objects test covers the entity form.