Publish a reactions endpoint for bots: emoji reactions exist but have no documented API #232

Summary

Symphony users can react to messages with emoji, but there is no documented REST endpoint for a bot to add, remove, or read reactions. Neither agent/agent-api-public.yaml nor pod/pod-api-public.yaml mentions reactions, and symphony-bdk-python has no reaction method, so a bot has no supported way to participate in a feature its users rely on.

The capability clearly exists server side. The Symphony web client reacts through an internal pod endpoint that already accepts a bot session token, so this looks like a matter of publishing an endpoint rather than building one.

Why it matters

Reaction-style acknowledgement is a common bot pattern on other chat platforms: a bot marks a request as seen, in progress, or done without adding a message to the conversation. Today a Symphony bot has to send a whole message, or a card, where one reaction would do.

It also cannot read reactions, so reactions cannot be used as lightweight input — for example approving a request by reacting to it.

Libraries hit this directly. In chatom, which abstracts over several chat platforms, Symphony is the only backend that cannot implement add_reaction, so the capability has to be advertised as unsupported even though the product supports it.

What the web client does

Observed in the Symphony web client on develop2.symphony.com, then confirmed by calling the same endpoints directly with a bot's sessionToken:

POST /maestro/reactions/v1/message            → 204 No Content
  add:    {"messageId": "<message id>", "emoji": "👍", "timestamp": 1791324381966}
  remove: {"messageId": "<message id>", "timestamp": 1791324381966}

GET  /maestro/reactions/v1/message?initialMessageId=<url-encoded message id>   → 200
  {"reactions": {"👍": [{"userId": 349026222366055, "ts": 1791324381966}]}, "sequenceNb": 1}

The read path the client itself uses is GET /client-bff/v1/streams/{streamId}/messages?...&includeReactions=true, and message payloads carry isLiked and likeCount.

Behavioral details, each verified against the sandbox:

• Message ids must be padded standard base64. The ids returned elsewhere in the API are URL-safe and unpadded, so _/- have to become //+ with = padding or the read side does not match.
• The emoji must be the literal character. A shortname such as thumbsup, or an empty string, returns 400 REACTIONS_INVALID_EMOJI.
• Removal omits the emoji field. An empty string is rejected, and posting the same emoji twice is idempotent rather than a toggle, so omitting the field is the only way to unreact.
• The client gates on properties named isReactionsReadEnabled, isReactionsWriteEnabled, and isReactionsWriteExternalEnabled, so pod-level entitlement handling already exists, including a separate rule for external and federated rooms.

The ask

1. Publish a reactions endpoint in agent-api-public.yaml or pod-api-public.yaml, covering add, remove, and list. Whether that is the existing route promoted as-is or a new one does not matter much, as long as it is in the specification and covered by the usual compatibility guarantees.
2. Have it honour the existing entitlements, so a pod that disables reactions or restricts them in external rooms keeps that behaviour for bots.
3. Please say in the response whether reactions are visible to the datafeed. A bot that can read reactions but not receive them has to poll, which does not scale.

Happy to help

I have opened a draft implementation against the Python BDK, which calls the current endpoint and documents why: finos/symphony-bdk-python#414. It follows the precedent of MultiAttachmentsMessagesApi, which is hand written for an endpoint the generated clients do not reach.

That draft is deliberately provisional. If a documented endpoint is published, the better outcome is to point the service at it, and I would rather contribute that version. Meanwhile chatom calls the current route behind an explicit, default-off flag documented as unsupported, which we would like to delete.

Environment

• Pod: develop2.symphony.com, Developer Certification sandbox
• symphony-bdk-python 3.0.0
• Observed 2026-10-06