messaging

The platform's message limits — length, buttons, callback data and formatting — and exactly where the core enforces each before a message reaches the connector.

The messaging block is required, even for a connector without the messaging capability, because it describes the platform, not the connector: the core composes every message once and needs to know what the platform will accept before it renders anything.

"messaging": {
    "max_length": 4096,
    "buttons_per_row": 8,
    "max_buttons": 100,
    "callback_data_bytes": 64,
    "supports_underline": true,
    "supports_spoiler": true,
    "supports_files": true
}

The fields

All seven are required.

Field	Type	Meaning	Enforced by
`max_length`	integer ≥ 1	The longest body the platform delivers, in characters of the canonical HTML.	The core splits a longer body into parts within the limit and calls `Messenger::send()` once per part; `Message::assertWithin()` then checks each part.
`buttons_per_row`	integer ≥ 1	How many actions may share one row.	`Message::assertWithin()`.
`max_buttons`	integer ≥ 1	How many actions one message may carry in total.	`Message::assertWithin()`.
`callback_data_bytes`	integer ≥ 1	The most bytes a callback button may carry back. Telegram's 64 bytes used to be tribal knowledge; here it is data.	`MessageAction::assertWithin()` throws on the developer's machine when a callback would be truncated.
`supports_underline`	boolean	Whether the platform can show `<u>`.	Published over `GET /connectors`; a renderer for a platform that cannot show it drops the tag, keeping the words.
`supports_spoiler`	boolean	Whether the platform has a spoiler (hidden until tapped) style.	Published over `GET /connectors`; the connector's renderer decides what a spoiler becomes.
`supports_files`	boolean	Whether the installation can send a file to a person.	The core refuses `sendFile()` itself with a `Configuration` failure when false, and never calls the port.

The canonical message

What the core hands a Messenger is a Subscriby\Connector\Data\Message: a body in the canonical HTML subset (<b> <i> <u> <s> <a href> <code> <pre> <blockquote>), a list of MessageActions built through four factories only (url, callback, copy, command), and a meta map keyed by connector for the one-platform extras every other connector ignores. Your TextRenderer turns the body into the platform's formatting; your Messenger lays the actions out.

The limits describe the platform, so state them as the platform documents them, not as your connector prefers. A connector that wants shorter messages than the platform allows composes nothing itself: the core writes the copy, and truncating it in the renderer loses meaning in ten languages.

Reading them from a connector

ConnectorManifest::$messaging is a MessagingLimits with the same seven fields as public properties. A connector never has to fold a long body itself: the core cuts a message over max_length into parts at paragraph, line and word boundaries, keeps the canonical tags balanced across them, and hands them to Messenger::send() in order with the buttons on the last part. Declare the platform's real limit, however low; the fake connector's 280 is what keeps that path exercised.

The fake connector's block

"messaging": {
    "max_length": 280,
    "buttons_per_row": 2,
    "max_buttons": 4,
    "callback_data_bytes": 32,
    "supports_underline": false,
    "supports_spoiler": false,
    "supports_files": false
}

Deliberately hostile: a core path that composes a 300-character message, a three-button row or a 40-byte callback fails against the fake in Subscriby's own suite. That is what keeps the core honest for the platform your connector brings.

What the loader checks

Every field present, every integer at least one, every flag a boolean. There is no kit rule beyond that: the block is data the core trusts, and review reads it against the platform's published limits.

messaging

The fields

The canonical message

Reading them from a connector

The fake connector's block

On this page