The Developer platform add-on includes three ways into your PreStartGo data, and they're shaped for different jobs: webhooks push, the REST API pulls, and the MCP server answers questions. Most real integrations use two of the three together; this is the guide to which does what.
| Surface | Shape | It shines when… | It's wrong when… |
|---|
| Webhooks | Push | You need to react — a defect raising a CMMS work order in seconds | You need history, bulk data, or anything beyond the three events |
| REST API | Pull | You need to read or write records — syncs, reports, bulk history | You're polling every minute for changes webhooks would push |
| MCP server | Query | A person wants answers — an AI assistant over your fleet, read-only | A system needs data — machines integrate via the API |
- React, then fetch. The webhook tells you that something happened; the API fetches whatever detail you need beyond its payload. This pair is the backbone of most event-driven integrations.
- Sync on your schedule. Nightly or hourly API pulls with cursors and date filters, for BI and warehousing — no webhooks needed.
- Ask, don't build. For "which excavators have an open critical defect right now?" asked by a human, the MCP server turns any capable AI assistant into that interface — no dashboard project required.
- Who consumes it — a system or a person? Systems → webhooks + API. People asking ad-hoc questions → MCP.
- Does it need to be immediate? Yes → webhooks (for the three events they cover). No → scheduled API pulls are simpler to operate.
- Does it write? Only the REST API writes. Webhooks are outbound-only; MCP is read-only by design.
- The three webhook events are the complete push surface —
check.completed, defect.reported, service.completed. Anything else event-shaped means polling the API for changes, deliberately conservative until more events earn their place.
- All three share the organisation's identity model — API keys scope them, the audit trail attributes them, and none crosses tenants.
- Rate limits apply to pulls — a webhook-driven design barely notices them; a poll-everything design meets them quickly. See API Errors and Rate Limits.
| Symptom | Likely cause | What to do |
|---|
| Polling loops hitting rate limits | Pull doing push's job | Move the trigger to webhooks; keep the API for the detail fetch |
| An assistant "can't update" a record via MCP | MCP is read-only by design | Writes go through the REST API |
| Needing an event webhooks don't cover | Only three events exist | Scheduled API delta pulls |
| Unsure where to start | — | Webhook → API fetch is the pattern that fits most first builds |