Reference · built on requestConnectorField service & CMMS

Limble CMMS

Assets, locations, tasks, parts, vendors, and purchase orders from Limble CMMS API V2, with signed webhooks.

About

Limble CMMS is a maintenance platform whose API V2 is served per region: api.limblecmms.com by default, with ca-api, au-api, eu-api, and 21cfr-api hosts. It exposes assets, locations, parts with quantities and usage, tasks covering work orders, preventive maintenance, and work requests, users, vendors, roles, teams, purchase orders, general ledgers, budgets, priorities, tags, statuses, bills, regions, and units of measure. Webhooks fire on assets, asset fields, locations, parts, purchase orders, purchase order items, tasks, and task instructions.

An operator on Fibric reads open tasks, part usage, and purchase order states, then proposes a new task, a work request decision, or a purchase order for your approval, each with a receipt.

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

  • Tasks from /v2/tasks filtered by asset, location, type, status, scheduled window, or completion date
  • Task parts, labor, comments, tags, instructions, and invoices through the task's meta shortcuts
  • Work request submissions with Pending, Approved, or Rejected status
  • Assets with custom fields, field history, logs, and linked parts
  • Parts with current quantities, usage, vendor associations, and purchasables
  • Purchase orders with items, comments, state, and permitted state transitions
  • Webhook posts for task, asset, assetField, location, part, po, poItem, and instruction events

Proposed actions

  • Target capability: propose a task through POST /v2/tasks with name, locationID, due time, and type (PM, unplanned or planned work order, work request)
  • Target capability: propose updating a task's assignment, due time, or top-level fields through PATCH /v2/tasks/{taskID}
  • Target capability: propose approving or declining a work request submission
  • Target capability: propose a purchase order, its items, and a state change through /v2/po
  • Target capability: propose a comment or parts on a task

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

What you can build

  • Decide routine work requests before the morning huddle

    Read Pending work request submissions, match them to open tasks and asset history, and propose approve or decline for a supervisor.

    With Work Order Aging, Backlog Priority

  • Draft the purchase order when usage outruns stock

    Read part usage and quantities, and propose a PO with items to the associated vendor when the reorder floor is crossed.

    With Purchase Order Draft, Spares Reorder

  • Create the PM the field history says is due

    Watch assetField webhook posts and field history, and propose a preventive maintenance task when a tracked reading crosses its interval.

    With Service Interval, Inspection Due

Requirements

  • A Limble account and its regional API host
  • A Super Administrator to generate the Client ID and Client Secret; the secret is shown once
  • At least one active limbleAPI key, without which webhooks do not fire
  • A receiver that answers webhook posts within 10 seconds
Authentication
HTTP Basic authentication with a Client ID and Client Secret, base64-encoded in the Authorization header, generated by a Super Administrator under Settings > Configuration > API Settings.

Limits

  • Rate limits per hour and per minute: GET 4000 and 360, PATCH 2000 and 240, POST and PUT 1000 and 240, DELETE 100 and 60
  • Batch requests are capped at 20 per hour and 5 per minute
  • A limit above an endpoint's maximum returns 422; a missing or non-positive limit defaults to 1000
  • Webhooks retry after 10 minutes, 1 hour, 2 hours, and 4 hours, then disable themselves

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 Limble CMMS ↗

Questions and answers

How are webhook posts validated?
Each post carries signature, timestamp, and token headers. The signature is an HMAC-SHA256 of timestamp plus token, keyed with your oldest limbleAPI key. A 200 marks success, a 406 marks received but ignored, and anything else is retried.
Which task types can the API create?
Four: 1 for Preventative Maintenance, 2 for Unplanned Work Order, 4 for Planned Work Order, and 6 for Work Request. Other types are not supported for creation, and a Work Request cannot carry a batchID.
What do the rate limit headers report?
X-RateLimit-Limit and X-RateLimit-Remaining for the hourly window, X-RateLimit-Minute-Limit and X-RateLimit-Minute-Remaining for the minute window, X-RateLimit-First-Call for the window start, and X-RateLimit-TTL when you are blocked.
Ask about Limble CMMS

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.