Reference · built on requestConnectorMessaging & notifications

Webex

Rooms, messages, memberships, and webhooks in Webex through the Messaging REST API with a bot or integration token.

Request accessPricing ↗

About

Webex is Cisco's collaboration suite; its messaging side is rooms, also called spaces, with memberships, messages, files, and cards. Its API sits at webexapis.com/v1 with Bearer tokens and RFC5988 Link-header pagination. A bot is created under My Webex Apps and receives an access token; in group rooms it sees only messages that @mention it, in 1-to-1 rooms it sees everything. An integration is an OAuth app that acts as a signed-in user with the scopes you pick. Webhooks post JSON to your URL when messages, memberships, rooms, or attachmentActions are created, updated, or deleted.

Through Fibric, an operator watches those webhooks and proposes a message, a card, or a file into a room for a person to approve.

This is a reference listing. It documents what Fibric would read from Webex 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

  • messages created and messages deleted webhooks, filterable by roomId, personEmail, mentionedPeople, and hasFiles
  • memberships created, updated, and deleted, plus rooms created and updated webhooks
  • attachmentActions created when someone submits a card
  • Messages in a room through GET /messages with roomId; a bot must add mentionedPeople=me
  • Files on a message through GET on the /contents URL, subject to the organization's anti-malware scanning
  • Room rosters through the memberships resource

Proposed actions

  • Target capability: propose a message with POST /messages to a roomId or toPersonEmail, text or markdown up to 7439 bytes
  • Target capability: propose a card in the attachments field and read the reply as attachmentActions
  • Target capability: propose a file on a message, one file per message, up to 100 MB
  • Target capability: propose a threaded reply using parentId
  • Target capability: propose registering a webhook with POST /webhooks, with a secret for payload signing

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

What you can build

  • Comfort complaints from the facilities room

    A message in the facilities room that mentions the bot is matched to the zone and its current setpoint. The operator proposes a reply and a work order; a person approves both.

    With Comfort Complaint

  • Leak alerts with a card to acknowledge

    A leak sensor trip becomes a proposed card in the building's room with an Acknowledge button. The press returns as attachmentActions created and is written to the event record.

    With Leak Response

  • Overdue work orders in one thread per site

    Work orders past their due date are listed in a single threaded message per site with owners named. The manager approves the post; replies land under it.

    With Work Order Aging, Certificate Expiry

Requirements

  • A Webex account with access to My Webex Apps to create a bot or an integration
  • The bot added to each group room it must read; members add it, and it sees only messages that @mention it
  • A publicly reachable HTTPS URL for webhooks; Webex disables a webhook after 100 failed deliveries within five minutes
  • For a messages webhook the token carries spark:messages_read; for memberships, spark:memberships_read
Authentication
A bot access token from My Webex Apps, or an integration's OAuth 2.0 token with scopes such as spark:messages_read and spark:messages_write, sent as Authorization: Bearer.

Limits

  • Webhook payloads carry metadata and encrypted content only; the text is fetched afterwards with GET /messages/{id}
  • Rate limits are layered and not fully documented; a 429 carries Retry-After, 3600 seconds in the documented example
  • In group rooms a bot receives messages:created only for messages that mention it
  • Each Webex user account holds at most 20 integrations; personal webhooks are capped at 30,000 per user

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 Webex ↗

Questions and answers

Why does the webhook not include the message text?
Webex webhook notifications carry metadata and encrypted content only. When messages created fires, your receiver calls GET /messages/{id} with its token to read the text and files. That keeps message bodies off the public callback URL.
What can a bot see in a room?
In group rooms, only messages that @mention it, and listing messages requires mentionedPeople=me. In 1-to-1 rooms it sees every message from the user. Bots are on the room roster and hold the space's encryption keys, so the mention rule is a delivery filter rather than an access control.
How are webhook deliveries authenticated?
Supply a secret when creating the webhook. Each delivery then carries an X-Spark-Signature header, an HMAC-SHA1 over the raw request body, that your receiver checks. Webhooks need a 2xx response and are disabled after 100 failed attempts within five minutes.
Ask about Webex

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 Webex 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