REST API
Manage1to1 includes a REST API so your district can connect your own reporting, dashboards, and automations. You can read your data (devices, users, buildings, tickets, incidents, invoices, and custom fields) and, when you grant the permission, write it too — create and update devices and users, open and update tickets, log incidents, and create invoices and record payments.
Access is controlled by tokens that you issue yourself. Each token is limited to exactly what you allow — which areas, and whether it may only read or also make changes — and can only be used from network locations you approve, so you decide precisely what any integration can reach.
Actions a token takes are recorded in your Activity Log against the administrator who created the token — so a change made by an integration is just as traceable as one made by a person in the admin area. Create operations also support safe retries, so a dropped connection won't accidentally create something twice.
Every instance hosts its own interactive API documentation, kept perfectly in step with your version. You can browse every available endpoint, see the exact fields returned, and try live requests right from the page. This guide covers how to issue a token and where to find that reference. Open API Docs from the console for the endpoint details themselves.
Finding the API Console
Go to Settings → API Tokens.
From here you can:
- Issue a new token with a name, a set of permissions, and approved network locations
- Review existing tokens: their name, permissions, when they were last used, and when they expire
- Revoke a token the moment it is no longer needed
- Open the API Docs, the interactive reference for your instance

Issuing a Token
Select Create Token and complete the form:
- Name: a short, recognizable label (for example,
State reporting exportorNightly device sync) so you can tell your tokens apart later. - Permissions: choose only what this token may do. Permissions are grouped by area (devices, users, buildings, tickets, incidents, invoices, custom fields, and more) and split into read and write — so a token can be read-only, or allowed to make specific kinds of changes. A token can never do more than the permissions you grant it.
- Approved locations: enter the network locations allowed to use this token. This is required. A token with no approved location cannot be used at all.
- Expiration: every token has an expiry date, so access never lingers indefinitely.
For your security, the full token is shown only once, at the moment you create it. Copy it and store it somewhere safe right away. If you lose it, you cannot see it again. Simply revoke it and issue a new one.
Approved Locations
Every token is tied to the network locations allowed to use it. We strongly recommend listing single addresses (the specific locations your integration actually runs from) rather than broad ranges.
- Single addresses are entered directly, one per line.
- Ranges are supported when a single address isn't practical, but only up to a modest span. Very broad ranges are rejected, so a token can never be usable from anywhere on the internet.
If a request arrives from a location that isn't on the token's approved list, it is refused before any data is returned.
Choosing Permissions Well
The safest token is the one that can do the least. When you set up an integration, grant only the permissions it genuinely needs — and prefer read over write unless the integration truly needs to make changes:
- A reporting export that only charts data needs read access to those areas, nothing more.
- A help-desk dashboard needs only ticket and incident read access.
- An integration that opens tickets needs ticket write; a device-inventory sync that creates devices needs device write.
If an integration's needs change later, issue a new token with the right permissions and revoke the old one.
Some permissions grant access to personal information about students and staff. These are clearly marked when you choose permissions, so you can be deliberate about which tokens are allowed to read them.
Revoking a Token
If a token is no longer used, or you suspect it has been exposed, revoke it from Settings → API Tokens. Revocation takes effect immediately, and any further requests using that token are refused at once. Issue a fresh token for anything that still needs access.