Errors
This document describes the error model and all error responses supported by the Transport API.
Error Envelope
All error responses conform to a common JSON schema:
Error Response Structure
{
"data": {
"status": "FAILED",
"errorLog": "Human-readable description of what went wrong"
}
}- status — The request status (
FAILEDfor errors). - errorLog — A human-readable description of the problem.
HTTP Status Codes
| Status | Meaning | Typical Scenarios |
|---|---|---|
| 400 Bad Request | Validation or formatting issue | Missing or invalid fields, unrecognised destination code, invalid parameter format |
| 401 Unauthorized | Token cannot be verified | Expired or malformed Bearer token |
| 403 Forbidden | Token not provided or invalid | Missing Authorization header, invalid credentials |
| 404 Not Found | Resource not found | No request found with the given requestId, client not found |
Endpoint-specific Error Notes
POST /v1/sign-requests/train-announcements
- 400 Bad Request
- Missing or invalid fields in the request body.
- Unrecognised destination CRS/TIPLOC code.
- Invalid parameter combinations.
- 401/403 Unauthorized/Forbidden
- Bearer token is missing, expired, or invalid.
POST /v1/sign-requests/train-announcements — Example Error
{
"data": {
"status": "FAILED",
"errorLog": "Destination not recognized."
}
}GET /v1/sign-requests/{requestId}
- 400 Bad Request —
requestIdis missing or not in the expected format. - 404 Not Found — No request found with the given
requestId.
GET /v1/sign-requests/{requestId} — Example Error
{
"data": {
"status": "FAILED",
"errorLog": "Request not found."
}
}Client Guidance
- Do not retry 400 responses without correcting the request — they indicate client-side issues.
- 401/403 responses typically mean you need to re-authenticate and obtain a fresh token.
- Always read the
errorLogfield for additional context to fix the failing request quickly.
Last updated on