Reference · built on requestConnectorField service & CMMS

Brightly Asset Essentials

Work orders, assets, meter readings, parts, and purchase orders from Brightly Asset Essentials over its REST API.

Request accessPricing ↗

About

Brightly Asset Essentials is a cloud CMMS from Brightly Software, a Siemens company, used by schools, local government, manufacturers, and clubs to run maintenance. It stores work orders, assets and their meter readings, parts and part locations, purchase orders, users, locations, sites, and PM procedures. Its REST API sits at your application URL plus /api, and every endpoint appears in the Swagger documentation Brightly publishes.

Through Fibric, an operator polls /v2/workorders/searches for changed work orders, reads assets and meter readings, and proposes a new work order, a meter reading, or a field-limited update. Nothing is written until you approve, and every approved write is logged with its reason.

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

  • Work orders through /workorders, and filtered bulk reads through POST /v2/workorders/searches and /v2/workorders/quicksearches
  • Work orders modified in a window, using utcDateModifiedStart and utcDateModifiedEnd on /workorders or DateLastModified filters in /searches
  • Work order labor, parts, and equipment usage through the v1 Workorder and v2 WorkOrderPart resources
  • Assets through /assets, with asset statuses and hierarchy, and meter readings through /v2/meterreadings
  • Parts, part locations, and part suppliers through /parts, and purchase orders through /purchaseorders
  • Locations, sites, users, PM procedures, and inventory transactions through the v2 Location, Site, User, PMProcedure, and Inventory resources
  • Custom fields on work orders, assets, and users, returned on single-object GETs or with customFields=True on bulk requests

Proposed actions

  • Target capability: propose a work order through POST /v2/workorders with its WOStatusId, PriorityId, and asset
  • Target capability: propose a partial update with PUT and a FieldsToUpdate array, so only the named fields change
  • Target capability: propose a meter reading on an asset through POST /v2/meterreadings
  • Target capability: propose labor or part lines on a work order through the WOLabor and WOPart resources

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

What you can build

  • Rank the open backlog by site

    A /searches query filtered on WOStatus and DateCreated returns open work orders per location. The operator proposes which to escalate or reassign and records the reason.

    With Work Order Aging

  • Turn a meter reading into a PM order

    Readings from /v2/meterreadings show when an asset crosses its service interval. The operator proposes the PM work order on that asset for your approval.

    With Service Interval

  • Restock parts a job used up

    Part lines on completed work orders and part locations show what dropped below minimum. The operator drafts the purchase order through /purchaseorders and waits for your approval.

    With Parts Reorder

  • Send a request to the right crew

    New requests arrive as work orders with a Work Category. The operator proposes the assignee and priority for each; you approve or change it.

    With Request Routing

Requirements

  • A Brightly Asset Essentials account and a login reserved for API use, with its time zone set to UTC as Brightly recommends
  • An Expires value in minutes on each /login call; Brightly's examples use 120, after which you log in again
  • Your company's application URL, such as https://assetessentials.dudesolutions.com/CompanyNameABC, with /api appended
  • The internal ID of each object, not its NO number, when you GET or PUT a single work order or asset
Authentication
A username and password posted to /login with CultureCode and Expires, which returns a token you send on every request as Authorization: Basic {{AE_TOKEN}}.

Limits

  • Brightly states there are no rate limits today and may impose them in the future
  • /v2/workorders has no bulk GET; filtered reads go through /searches or /quicksearches, which accept only POST
  • A PUT without FieldsToUpdate replaces every field, and any field you omit is emptied
  • Responses are paged with PageNumber and PageSize, default 10, and the API documentation lists no webhooks, so change detection polls modified-date filters

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 Brightly Asset Essentials ↗

Questions and answers

How does the Asset Essentials API authenticate?
POST LoginName, Password, CultureCode, and Expires as form fields to /login. The response body is a token. Send it on every later request as Authorization: Basic followed by the token. It expires after the number of minutes you set in Expires; Brightly's examples use 120.
How do I read only work orders that changed?
Two ways. On /workorders, pass utcDateModifiedStart and utcDateModifiedEnd as query parameters. On POST /v2/workorders/searches, filter on DateLastModified with both StartValue and EndValue set; omitting either returns nothing. Requests take UTC and responses use the account's local time, so keep the API account on UTC.
Is there a full endpoint list?
Yes. Brightly's API Resources page links to the Swagger documentation, which groups endpoints by resource: v1 and v2 Asset, Workorder, Part, PurchaseOrder, Location, Site, User, PMProcedure, Inventory, MeterReading, Tasks, and TaskBooks among others.
Ask about Brightly Asset Essentials

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 Brightly Asset Essentials 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