Reference · built on requestConnectorMessaging & notifications

Matrix

Rooms, events, and room state on any Matrix homeserver through the Client-Server API or an application service.

Request accessPricing ↗

About

Matrix is an open protocol for federated messaging, published by The Matrix.org Foundation as a versioned specification (v1.19 at the time of writing). Every message is a JSON event with a type such as m.room.message, posted into a room identified as !opaque_id:domain. Rooms carry state events for names, membership, and power levels, and homeservers replicate events between each other on an eventually consistent basis. The specification has five API surfaces: Client-Server, Server-Server, Application Service, Identity Service, and Push Gateway.

Through Fibric, an operator joins the rooms you assign, follows their timelines, and proposes a message, an invite, or a redaction for a person to approve before it is posted.

This is a reference listing. It documents what Fibric would read from Matrix and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Timeline and state events for joined rooms through GET /_matrix/client/v3/sync, with a saved filter to lazy-load members
  • Room history through GET /_matrix/client/v3/rooms/{roomId}/messages
  • Current room state through GET /_matrix/client/v3/rooms/{roomId}/state
  • Read receipts and fully-read markers posted by other members of the room
  • As an application service: events pushed by the homeserver to PUT /_matrix/app/v1/transactions/{txnId} for the users, rooms, and aliases in its registered namespaces
  • Session state changes, including M_UNKNOWN_TOKEN with soft_logout when a token expires

Proposed actions

  • Target capability: propose an m.room.message event with PUT /_matrix/client/v3/rooms/{roomId}/send/m.room.message/{txnId}
  • Target capability: propose inviting a user to a room with POST /_matrix/client/v3/rooms/{roomId}/invite
  • Target capability: propose redacting an event the account sent with PUT /_matrix/client/v3/rooms/{roomId}/redact/{eventId}/{txnId}
  • Target capability: propose a state event with PUT /_matrix/client/v3/rooms/{roomId}/state/{eventType}/{stateKey}
  • Target capability: propose marking a room read up to an event with POST /_matrix/client/v3/rooms/{roomId}/read_markers

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • On-call handoff in the team room

    At shift change the operator drafts a handoff message listing open incidents and who owns each. A person approves it and it posts to the on-call room as one event.

    With On-call Handoff

  • Outage notice to a shared room

    When monitoring confirms an outage, the operator proposes a notice for the customer-facing room. Approval posts it; a later redaction proposal retracts it if the alert was false.

    With Outage Notice

  • Daily exceptions gathered into one message

    Exceptions from other systems are collected into a single m.room.message each morning. Replies in the room record who picked up each item.

    With Exception Digest, Action Follow-up

Requirements

  • A Matrix homeserver whose Client-Server API Fibric can reach over HTTPS
  • A dedicated account on that homeserver, joined to each room it should read or post in
  • For the application service model: a registration file with as_token, hs_token, sender_localpart, and namespaces, installed by the homeserver administrator
  • For rooms using m.megolm.v1.aes-sha2 encryption: device keys managed through the /_matrix/client/v3/keys endpoints
Authentication
An access token for a homeserver account, sent as Authorization: Bearer and obtained through POST /_matrix/client/v3/login or, on homeservers that advertise it at GET /_matrix/client/v1/auth_metadata, an OAuth 2.0 flow; or an application service as_token from a registration file the homeserver administrator installs.

Limits

  • Events arrive by polling /sync, one stream per account; the push model exists only for a registered application service
  • Homeservers rate-limit with M_LIMIT_EXCEEDED and HTTP 429; the Retry-After header says how long to wait
  • A transaction ID is scoped to one device and one endpoint; a repeat with the same ID and path returns the original event_id
  • An application service observes and injects events but cannot block or edit what other users send

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Matrix ↗

Questions and answers

Does Fibric need a webhook from the homeserver?
No. A client account receives events by calling GET /_matrix/client/v3/sync and resuming from the token the last response returned. A homeserver only pushes events outward to an application service, which the administrator registers with a file containing as_token, hs_token, and namespaces.
What happens if the same message is sent twice?
Sends carry a transaction ID in the path. The specification says the homeserver should treat a request with the same transaction ID and the same path as a retransmission and return the same response, including the original event_id. The scope is one device and one endpoint.
Can it read encrypted rooms?
Only with keys. Group messages in encrypted rooms use m.megolm.v1.aes-sha2 and one-to-one sessions use m.olm.v1.curve25519-aes-sha2. The account must upload device keys with POST /_matrix/client/v3/keys/upload and take part in key exchange. Unencrypted rooms need none of this.
Ask about Matrix

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Matrix through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy