A district's systems all know things the help desk should know. The rostering system knows a student enrolled. HR knows someone starts Monday, and that someone else left on Friday. None of that reaches the help desk unless a human retypes it.
The usual answer is a paid integration tier, a services engagement, or no API at all, so districts end up with brittle workarounds and a platform they can only use the way it was imagined.
POST /api/v1/tickets. Your rostering system, provisioning scripts, monitoring tools, or a scheduled job can open a ticket.
Fetch one ticket or list and filter them by your own reference, by date window, by source, or by status. Paginated oldest-first so a window can be walked reliably.
Send your own client_ref and a retry returns the original ticket instead of a duplicate, enforced by a unique index rather than by hopeful application logic.
Tenant-scoped bearer tokens, hashed at rest, rate-limited, and write-only by default. Reading requires a scope an admin turns on deliberately, and that action is audit-logged.
PowerShell, curl and Python, in-app, so the person wiring it up is not reverse-engineering anything.
The onboarding and offboarding flow is where this pays for itself. Tie rostering into the help desk and a new enrolment or a new hire opens the ticket to deploy a device; a departure opens the ticket to reclaim one. The work still happens, but it stops depending on someone remembering to create it.
The published surface is ticket-shaped: create, read, filter, plus the hotspot endpoint built for a device-lending workflow. It is not yet a full API over every object in the platform. New endpoints get built when a district asks for one, and when they are built, they become available to every district on the platform rather than staying a private arrangement.
Every feature is in every plan, including this one. Set it up yourself in an afternoon, or have us walk you through it.