Reference · built on requestConnectorMessaging & notifications

xMatters

Events, on-call shifts, people, devices, groups, and incidents from xMatters through the xmAPI and Flow Designer triggers.

Request accessPricing ↗

About

xMatters is an on-call and incident notification service from Everbridge. Its REST API, the xmAPI, is served per company at https://<company>.xmatters.com/api/xm/1/ and covers events, people, devices, groups, shifts, on-call, incidents, services, subscriptions, scheduled messages, and temporary absences. Flow Designer runs workflows from triggers: HTTP requests, email, and alert activity such as status updates, device deliveries, responses, comments, and escalations.

Through Fibric, an operator reads who is on call and which events are active, then proposes a new event for a group, a change of event status, a timeline note on an incident, or a temporary absence with a replacement. You approve. It runs once and leaves a record of what changed and why.

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

  • Events with their annotations and user delivery records through GET /events, /events/{id}/annotations, and /events/{id}/user-deliveries
  • Who is on call per group, including shift gaps with include=GAPS, through GET /on-call, and a recipient-centric view through GET /on-call-summary
  • People, devices, groups, group members, shifts, and sites through GET /people, /devices, /groups, /groups/{id}/members, and /groups/{id}/shifts
  • Incidents with severity, status, and impacted services through GET /incidents
  • Event audit records such as EVENT_ANNOTATED and RESPONSE_RECEIVED through GET /audits?eventId=
  • Signals received by xMatters and events held back by flood control through GET /signals and GET /event-suppressions
  • Alert activity sent to your URL by a Flow Designer flow: status updates, device delivery updates, responses, comments, escalations, and targeted recipient failures

Proposed actions

  • Target capability: propose triggering an event to named people, devices, or groups through a form's /forms/{id}/triggers URL, with priority and expirationInMinutes
  • Target capability: propose suspending, resuming, or terminating an event through POST /events with the event id and status
  • Target capability: propose creating or modifying an incident, or adding a note through POST /incidents/{id}/timeline-entries
  • Target capability: propose a temporary absence with a named replacement for a group member through POST /temporary-absences
  • Target capability: propose a scheduled message to a group through POST /scheduled-messages

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

What you can build

  • Hand off on-call with the gaps visible

    The operator reads GET /on-call with include=GAPS for each group and proposes a temporary absence with a named replacement wherever a shift has no one. You approve; the absence is created once.

    With On-call Handoff

  • Notify responders when a system goes down

    When an uptime check fails, the operator drafts an event for the responsible group with priority and expiry and proposes it. You approve before anyone is paged.

    With Uptime Response

  • Tell a site about severe weather

    A weather warning for a site becomes a proposed event to the people at that site, with the warning text and a response option. User delivery records show who was reached.

    With Severe Weather Notice

  • Announce a planned shutdown

    For a scheduled utility shutdown, the operator proposes a scheduled message to the affected groups and records responses as they arrive through the audit feed.

    With Shutdown Notice

Requirements

  • An xMatters company instance and its base URL of the form https://<company>.<deployment>.xmatters.com/api/xm/1/
  • An integration user assigned xMatters' REST Web Service User role, or role permissions matching each endpoint you call
  • Historical data access, which Client Services enables per role; runtime data covers the last 30 days
  • A workflow with an enabled form or HTTP trigger, and permission to initiate that form, before events can be triggered
Authentication
HTTP Basic with an xMatters user's web login and password, or an API key prefixed x-api-key- as the username and its secret as the password; OAuth 2.0 password grant with the company client ID issues bearer and refresh tokens.

Limits

  • Requests per minute are capped by pricing plan; over the cap, xMatters returns 429 and does not queue the request
  • Runtime data is retained for 30 days; older event and on-call history depends on the pricing plan
  • GET /on-call accepts up to 30 groups per request and returns 3 members per shift unless membersPerShift is set, to a maximum of 100
  • Pages hold at most 1000 results; the on-call summary excludes broadcast groups with more than 200 members

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

Questions and answers

Does xMatters send webhooks?
Through Flow Designer. Flows start from alert activity triggers, such as status updates, device delivery updates, responses, comments, and escalations, and steps in the flow can send HTTP requests to your endpoint. Existing outbound integrations for a form appear as triggers on the canvas.
What is the difference between events and alerts?
The web interface now calls events alerts. The xmAPI keeps the event properties, values, and labels unchanged, so GET /events and POST /events still apply. Only the status of an event can change after it is initiated: suspend, resume, or terminate.
How far back can on-call and event history be read?
Runtime data covers 30 days. Historical data, such as past on-call and user delivery records, reaches back as far as your pricing plan supports and needs a permission that Client Services enables for a role. Historical queries take an at parameter in UTC.
Ask about xMatters

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