Reference · built on requestConnectorBuilding management platforms

Willow

Twins, time series, insights, tickets, and events from a Willow digital twin instance.

Request accessPricing ↗

About

Willow is a digital twin platform for buildings from Willow. Each customer instance holds a knowledge graph: Models from the Willow ontology, Twins as nodes, and Relationships such as located in and is fed by. Capability twins carry time series. Skills analyze that telemetry and raise Insights. Tickets track the resulting work. Events record bookings, schedules, weather forecasts, and utility demand response windows. Public API v3 sits at {instance}.app.willowinc.com/api/v3.

Through Fibric, an operator reads twins, telemetry, insights, and tickets from that instance, then proposes events and twin updates. You approve each one, and the record shows what was sent and why.

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

  • Models and the Willow ontology through GET /models and GET /models/{id}
  • Twins, counts, and the twin graph through POST /twins, POST /twins/ids, POST /twins/graph, and POST /twins/count
  • Outgoing and incoming relationships for a twin, such as located in and is fed by
  • Time series for capability twins: GET /time-series/{twinId} with start and end, bulk POST /time-series/ids, and latest values
  • Insights raised by Skills, with priority, lastStatus (open, inProgress, readyToResolve, resolved), occurrenceCount, and recommendation
  • Tickets with ticketStatus, ticketPriority (urgent, high, medium, low), assignees, dueDate, linked insightId, and attachments
  • Events and event types through POST /events, GET /events/{eventId}, and GET /events/types

Proposed actions

  • Target capability: propose an event such as a demand response window or schedule change through PUT /events, for your approval
  • Target capability: propose a twin property update through PATCH /twins/{id} once you approve it
  • Target capability: insert telemetry for a capability twin through POST /time-series, batched as an array of values

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

What you can build

  • Triage insights before they turn into tickets

    Read open insights with priority, occurrenceCount, and the twin they sit on, then propose which ones deserve a ticket today and which can wait.

    With Alarm Triage

  • Put a demand response window into the twin

    When the utility calls an event, the operator drafts a Willow event with start and end times and the affected locations. You approve; PUT /events records it.

    With Event Response

  • Watch ticket age by priority

    List tickets by ticketStatus and dueDate, group by ticketPriority, and flag urgent ones past due with their linked insight.

    With Work Order Aging

  • Feed a failure forecast with twin history

    Pull time series for the capability twins under one asset through POST /time-series/ids and hand the history to the maintenance model.

    With Predictive Maintenance

Requirements

  • A Willow instance and a client application created under Public API v3 in the Willow User Management app
  • A Client Id and a generated Client Secret, with permissions added on the Assignments tab
  • Optionally, an assignment restricted to one Location if the connector should see one site only
Authentication
OAuth 2.0 client credentials grant: a Client Id and Client Secret exchanged at POST /oauth2/token for a Bearer token that expires in about an hour.

Limits

  • Rate limit of 20 requests per 10 seconds on /v3/twins/* and /v3/time-series/*, fixed window; the API answers 429 above it
  • The v3 reference lists tickets and insights as list and retrieve only; no path creates a ticket or changes an insight status
  • Authorization code grant is not yet supported, so every call runs as the client application, not a named user
  • No webhook or subscription mechanism is documented; the connector finds changes by polling

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

Questions and answers

Which Willow endpoints does the connector read?
Models, Twins, Relationships, Time Series, Insights, Events, and Tickets under /api/v3 on your instance. Twins and time series are read in bulk through POST /twins/ids and POST /time-series/ids to stay under the rate limit. Ticket lists page at 100 by default and up to 1000.
Can Fibric create tickets in Willow?
Not through Public API v3 as published. POST /tickets lists tickets and GET /tickets/{ticketId} retrieves one. Ticket Metadata endpoints add categories, job types, service-needed entries, and sub-statuses. Fibric reads tickets from Willow and proposes the work order in the system you name.
How is the rate limit enforced?
Per endpoint group. /v3/twins/* and /v3/time-series/* each allow 20 requests in a fixed 10-second window. Above that, Willow returns HTTP 429 and suggests bulk queries. The connector batches ids into the bulk endpoints and paces history loads accordingly.
Ask about Willow

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