The API

Creating a token

An administrator creates tokens under More › API Tokens. Give the token a name describing what it is for, and tick only the abilities it needs:

Making a request

Send the token in an Authorization header:

curl -H "Authorization: Bearer YOUR_TOKEN" \
     -H "Accept: application/json" \
     https://app.academiqedu.com/api/v1/students

Check a token works with /api/v1/me, which returns the institution it belongs to and the abilities it holds.

Endpoints

All endpoints are GET and live under /api/v1.

Paging

Responses are paged. Use page and per_page; per_page is capped at 200 so a single request cannot pull the whole school. Every response carries a meta block:

{
  "data": [ … ],
  "meta": {
    "current_page": 1,
    "last_page": 7,
    "per_page": 50,
    "total": 312
  }
}

Rate limit

Sixty requests a minute. Beyond that the API responds 429; wait and retry rather than looping.

Why it is read-only

The API does not create, change or delete anything. Writing through an integration multiplies the ways a school's records can be corrupted, and the integrations schools actually ask for — pushing results to a portal, reconciling fees, syncing a roll — only need to read. If you need to write, tell us what for; it is easier to add writes later than to take them back.

What a token can and cannot do

• A token only ever reaches your institution's records.
• A token can never do more than the person who created it. If their permissions are reduced, the token's access is reduced with them — so a token is not a way around a role.
• Revoking a token stops it immediately. Revoke one the moment it is no longer needed, or if it may have been exposed.
• Creating and revoking tokens is written to your activity log.