Reference · built on requestConnectorBuilding management platforms

Mapped

Buildings, floors, spaces, things, and point series from Mapped, one GraphQL graph typed with the Brick schema.

Request accessPricing ↗

About

Mapped is a building data platform from Mapped. It takes device and point data from building systems through hardware or cloud gateways and Cloud Connectors, then normalizes it into one graph typed with the Brick schema: Sites, Buildings, SubBuildings, Floors, Spaces, Zones, Things, and Points. One GraphQL endpoint at api.mapped.com/graphql serves the whole graph, along with Work Orders synced from a connected CMMS.

Through Fibric, an operator reads the graph and point series, watches for changes by webhook or live query, and proposes what to do next for your approval. Each proposal carries its evidence: which points, which window, which building.

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

  • Sites, Buildings, SubBuildings, Floors, Spaces, and Zones, typed with the Brick schema through the type and exactType fields
  • Things such as VAVs, thermostats, and Lighting_Equipment, with hasDeviceModel and manufacturedBy where the source reports them
  • Point values over time through the series field, with startTime, endTime, latest, and stateTexts for coded numeric states
  • Point aggregations (avg, sum, min, max, count) by MINUTE, HOUR, or DAY period
  • Work Orders synced from a CMMS, with jobStatus, jobPriority, dueDate, and relatesTo links to places and things
  • Gateways and Cloud Connectors: which exist, their details, and which buildings they are assigned to
  • Change notifications by webhook: new time series for chosen pointIds, or a changed live query result

Proposed actions

  • Target capability: propose a name, exactType, or geoshape change on a Space or Floor through updateSpace and updateFloor, for your approval
  • Target capability: register a live query and webhook target (createLiveQuery, createWebhookTarget) so point and graph changes push to you

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

What you can build

  • Catch a zone that drifts off setpoint

    Read a zone's temperature and setpoint points as series, compare them per HOUR, and propose a check of the Thing that feeds the zone when the gap persists.

    With Setpoint Drift

  • Find points that stopped reporting

    A live query on the points of one building fires a webhook when series stop arriving. The operator lists the silent points by floor and space and proposes who looks first.

    With Sensor Health

  • Age work orders against the assets they touch

    Read Work Orders with jobStatus, dueDate, and relatesTo, then flag the ones past due on equipment that also shows abnormal series.

    With Work Order Aging

  • Audit after-hours run time by space

    Aggregate occupancy and equipment state points by DAY outside the schedule, and propose the spaces whose equipment ran while unoccupied.

    With After-Hours Audit

Requirements

  • A Mapped organization with buildings onboarded through a hardware or cloud gateway, or a Cloud Connector
  • A Personal Access Token from the Mapped Console with the read scopes your role allows
  • An ADMIN role for any token that carries write scopes; an EXPLORER can only mint read-only tokens
  • A reachable HTTPS endpoint for webhook delivery, with no auth or Basic auth and optional HMAC-SHA256 signing
Authentication
A Personal Access Token minted in the Mapped Console, sent as Authorization: token <value> with Content-type: application/json.

Limits

  • The guides document no way to write a point value or command equipment; control stays with the source system
  • Personal Access Tokens do not expire until revoked, so rotation is your responsibility
  • Gateway provisioning happens between your network team and Mapped support, outside the API
  • Rate limits and pagination are not stated on the public guide pages

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

Questions and answers

Can Fibric write a setpoint through Mapped?
No. The Mapped guides document reading points and series, plus mutations for sites, buildings, floors, spaces, tokens, live queries, and webhook targets. They document no point write or equipment command. Fibric reads through Mapped and proposes control changes through the connector that owns the equipment.
How does Fibric learn about changes without polling?
Through Mapped webhooks. A target created with createWebhookTarget fires when new time series arrives for the pointIds you name, or when a live query's result changes. Payloads carry pointId, timestamp, and value, or lastResult and liveQueryId. Delivery retries default to 5 attempts.
Which token does the connector need?
A Personal Access Token from the Mapped Console, sent as Authorization: token <value>. Scopes follow your role. An EXPLORER can only mint read-only tokens; an ADMIN can add write scopes. Tokens live until you revoke them, so keep one per integration and rotate on your own schedule.
Ask about Mapped

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