SyncroMSP

MSP ticketing, RMM and billing with SyncroMSP — API spec: https://api-docs.syncromsp.com/swagger.json (OpenAPI 3.0).

The API is REST and per-tenant: the only server the spec declares is https://{subdomain}.syncromsp.com/api/v1, authenticated with Authorization: Bearer <token>.

• Actions: List Tickets, Create Ticket, Update Ticket, Add Ticket Comment, List Customers, Create Customer, List Invoices, List RMM Alerts.
• Triggers: New Ticket, New Customer, New RMM Alert — all polling.

Connection: two fields, because the base URL is per-tenant.

1. Subdomain — the part before .syncromsp.com in the URL you sign in at, e.g. acme for https://acme.syncromsp.com. acme.syncromsp.com and the full URL are accepted too and get trimmed down. Without it there is no base URL to call.
2. API Token — in Syncro go to Admin > API - API Tokens (Admin may sit under the More menu), click + New Token in the upper right, name it, optionally set an expiry, and tick the permission checkboxes it needs. Syncro shows the token only once.

Connecting calls GET /me, which returns the user, the tenant's own subdomain and the token's permission map — so a token pasted against the wrong subdomain is rejected at connect time with a message naming the account it actually belongs to, rather than failing later inside a flow.

Notes

• Permission-scoped tokens. Each token carries its own per-endpoint checkboxes, and an endpoint whose box is unticked answers 403 even though the token is perfectly valid. The piece maps 401/403 to a message that says which path was refused and points back at Admin > API - API Tokens. For everything here, tick at least Tickets – List/Search, Create, Edit, Customers – List/Search, Create, Invoices – List/Search and RMM Alerts – List.
• Polling, not webhooks. Syncro publishes no webhook-management API — its outbound webhooks are configured by hand in the UI under Administration > Notification Center, and nothing in the OpenAPI spec creates, lists or deletes them. So all three triggers poll and dedupe on created_at (DedupeStrategy.TIMEBASED). New Ticket and New RMM Alert narrow the window with the documented created_after filter; the customer list has no such filter, so New Customer sorts newest-first and stops paging at the first record older than the previous poll. Each poll reads at most 4 pages of 25 records, which keeps a busy tenant well inside Syncro's rate limit at the cost of missing more than ~100 records created between two polls.
• Rate limit. Syncro allows 180 requests per minute per IP address. HTTP 429 is surfaced with that number in the message.
• Collection keys differ per endpoint. Responses come back as { tickets: [...] }, { customers: [...] }, { invoices: [...] } and { rmm_alerts: [...] }, each alongside { meta: { total_pages, page } }. List actions return the rows, a count and that meta.
• Ticket statuses are read live from GET /tickets/settings, because Syncro accounts customise them. If the token cannot read settings the dropdown falls back to the documented defaults (New, In Progress, Resolved, Invoiced, Waiting for Parts, Waiting on Customer, Scheduled, Customer Reply) rather than blocking the action. List Tickets additionally offers Not Closed, which Syncro accepts as a filter only.
• Priority is free text: the spec's only example is High and priority labels are configurable per account, so the piece does not pretend to know the full list.
• Ids are numeric. Customer ID, Ticket ID, Contact ID and Ticket Type ID are Syncro's internal integers — note the ticket id is not the ticket number customers see. Use List Customers / List Tickets to look them up, or wire them from an earlier step.
• Every call has a 30 s timeout, so a stalled request cannot wedge a flow.
• No custom API call action. A passthrough would hand this connection's permission-scoped token to an arbitrary user-supplied path.