Error codes
The Teach 'n Go API uses standard HTTP status codes, but with one important exception: unknown resources do not return HTTP 404. Instead, they return HTTP 200 with a status field in the response body set to a failure value. Always check the status field in the response body — do not rely on the HTTP status code alone to detect business logic errors.
HTTP status | Meaning |
200 | Request processed — check the |
400 | Malformed request — the request body or URL could not be parsed |
401 | Bad or missing API key |
403 | Missing authentication parameter, or your plan does not include API access |
422 | Validation failure — the request was understood but a parameter value is invalid |
500 | Server error — retry the request; if it persists, contact support |
Pagination
Most endpoints support pagination via two query parameters:
per_page— number of results per pagepage— page number, starting at 1
Default page sizes vary by endpoint: most endpoints default to 20 results per page; the receipts and invoices endpoints default to 10.
Pagination metadata
Most endpoints return pagination metadata as flat fields in the response:
{
"total": 250,
"limit": 20,
"page": 1,
"total_pages": 13,
...
}
The student attendance and teacher availability endpoints are different — their pagination metadata is nested inside a meta object:
{
"meta": {
"total": 250,
"limit": 20,
"page": 1,
"total_pages": 13,
"server_time": "2024-01-15T10:00:00Z"
},
...
}
Fetching all records
On the student attendance and teacher availability endpoints, omitting the per_page parameter entirely returns all matching records in a single response with no pagination. Use this with caution on large datasets.
Polling with modified_since (teacher availability)
The teacher availability endpoint supports a modified_since parameter for efficient polling. On your first call, store the meta.server_time value from the response. Pass it as modified_since on your next call to receive only records changed since that timestamp.
Caveat: hard-deleted availability slots will not appear in a modified_since response. If a slot is deleted rather than edited, your integration will not be notified of the removal via this parameter alone. Periodic full syncs are recommended to catch deletions.