MaintainX API Guide for Contractors

One-line verdict: A public, readable-by-anyone API reference with self-generated keys and a 46-event webhook catalogue — that simply doesn’t exist below the Premium plan. Openness: 4 / 5 — rated 4 because MaintainX documents a full REST API with subscriptions and vendor-documented Zapier actions, held back from 5 by one clean plan gate.

The connection that works

Rung 1 — Direct connection. MaintainX (an Autodesk company, per its own API reference) publishes its REST API reference openly — endpoints, parameters, schemas, and error codes across Work Orders, Assets, Parts, Locations, Users, and more, readable by anyone before they spend a dollar. Sign-in is a bearer token you generate yourself at Settings → Integrations → API Keys — no developer application, no vendor-issued credential. Multi-organization accounts scope calls with an organization header.

The gate is printed on the reference itself: “API access is available on Premium and Enterprise plans.” Below that, in the vendor’s framing, there is no API access at all.

Verified at the endpoint level: Work Orders — the vendor’s own guide names the create endpoint, and documents GET / POST / PATCH custom requests against “any of the endpoints listed in the MaintainX API Documentation”; Teams — a documented create endpoint; Subscriptions — full create/read/update/delete for the webhook system. The wider entity surface — Assets, Locations, Parts, Vendors, Customers, Purchase Orders, Work Requests, Users — is verified as first-class API objects through the reference and its event catalogue (each carries change events); their individual CRUD verbs weren’t read out one by one in our pass, so object-by-object write claims beyond work orders, teams, and subscriptions are flagged below rather than assumed.

Webhooks (Subscriptions): the deepest catalogue in this wave — 46 event types, including NEW_WORK_ORDER, WORK_ORDER_STATUS_CHANGE, WORK_ORDER_OVERDUE, NEW_WORK_REQUEST, NEW_CUSTOMER, NEW_PURCHASE_ORDER, and NEW_ASSET. Each subscription carries a destination, an HMAC secret returned at creation, and a validation status (one honest wrinkle: a subscription can come back PENDING_APPROVAL, and the vendor’s advice is to contact support). Rate-limit behaviour is documented — per-user and per-organization quotas with limit/remaining/reset headers and a 429 when exhausted; the tight documented numbers belong to meter readings (manual readings 10 per 24 hours; automated batch readings 100 per 60 seconds), and general quotas vary by endpoint class, so no single headline number is honest here.

Bridge apps: a native Zapier app, documented by MaintainX itself — triggers New Work Order, Work Order Status Change, New Work Order Category Added; actions Create Work Order, Create Work Request, Create Work Order Comment, and more, authenticating with the same API key. MaintainX also documents feeding its own webhooks into Zapier’s Catch Hook for events the prebuilt triggers don’t cover. No native Make app was verified.

Can automate

• Work-order flow between systems — work orders can be created and patched from your other tools, and status changes fire events back the moment they happen.
• Overdue and request alerts — WORK_ORDER_OVERDUE and NEW_WORK_REQUEST are first-class events, so escalation and intake automation key off real signals, not polling.
• Asset and parts awareness — assets, parts (including quantity changes and transfers), and locations are event-carrying API objects, so inventory and equipment tools can stay in step.
• Purchase-order visibility — purchase orders are the platform’s money object and carry new/change/status events for your reporting.

Can’t automate

• Anything on a free or basic plan — the API is Premium/Enterprise only, per the vendor’s own reference.
• Invoices or payments — no such objects. MaintainX’s money object is the purchase order, not an invoice. Don’t let a quote translate one into the other.
• Per-object write claims beyond the verified three — UNVERIFIED. Assets, Parts, Locations, Vendors, Customers, and Purchase Orders are verified as API objects with events; each one’s individual create/update verbs weren’t read out in our pass. Customer creation specifically stays unverified (customer change events are verified).
• One headline rate limit — limits are per endpoint class; anyone quoting a single number is flattening the vendor’s own documentation.
• Instant webhook approval, guaranteed — the PENDING_APPROVAL status exists; a subscription may need a support nudge before it validates.

Hidden gate: The API only comes with Premium or Enterprise — on the cheaper plans there’s simply nothing to connect to. Everything after the plan is self-serve; the plan is the whole gate.

Build fit — what this platform supports well

• Maintenance workflow automation — the strongest fit: work orders are writable, events are rich, and the reference is public.
• Facilities reporting — assets, parts, and purchase orders as event-carrying objects feed dashboards without exports.
• Invoice Chase / AR — not here: no invoice or payment objects exist; AR lives in your accounting system.
• Review Engine — like every platform here, MaintainX has no verified reviews API (no review object exists in its catalogue), so the review ask runs on our system triggered by a job-completion signal — a work-order status change supplies it cleanly.

What this means for your shop

If your maintenance or facilities operation runs on MaintainX Premium or Enterprise, this is how an API should be sold: read the whole reference before you buy, generate your own key, subscribe to 46 event types. The diligence list is short — confirm the plan, respect that purchase orders are not invoices, and verify each object’s verbs against the public reference before quoting object-level writes. The reference being public makes that a ten-minute job, which is rather the point.