Common errors
FMS DevelopersThis article sits within the FMS Developers sectionHTTP status codes
The DfE Submission API uses standard HTTP response code conventions:
- 100 codes are informational
- 200 codes indicate success
- 300 codes indicate a redirection
- 400 codes indicate a client-side error
- 500 codes indicate a server-side error
Common status codes are:
| HTTP Status code | Message | Comments |
|
200
|
OK
|
This status code indicates that the request has been processed successfully
|
|
204
|
Deleted
|
Submission deleted successfully.
|
|
400
|
Bad Request
|
This status code indicates that the incoming request body or parameters do not conform with the OpenAPI/Swagger document which describes the API, this error code could also include specific message to indicate the problem in the requested payload.
|
|
401
|
Unauthorised
|
This status code indicates authentication or authorisation error. This could be sent due to various reasons such as missing JWT header, Invalid claims, Invalid subscription key etc. For security reasons, error responses for this status code will not include reasons.
|
|
403
|
Forbidden request
|
Forbidden request (Examples include API request to delete a submission which doesn’t belong to the Academy Trust).
|
|
404
|
Submission not found
|
Submission not found (Submission doesn’t exist for the Submission ID)
|
|
503
|
Service Unavailable
|
The API is temporarily unavailable because it is overloaded or down for maintenance. Please wait for a short time and try again.
|
|
504
|
Gateway Timeout
|
This status code indicates that there is a network connection problem within the layers of the API fulfilment stack.
|
API error codes
There are specific API error codes for the DfE Submission API. We are using a http status code to indicate a successful call to API or any failure. In case of validation failure or malformed payload HTTP error code 400.
Please see the API Guide for details of validation errors that may be returned on when a submission is made with a valid URN but with data element(s) that contain errors.
Http error code 400 / Bad Requests will provide an application error response formatted
as follows:
{ "type": (error type), <-- String identifying error types
"details": (details) <-- String array providing additional
details where applicable}
The following table documents the possible error types:
| Type | Details | Notes |
| coaValuePrecisionExceeds3dp | List of invalid CoA items | One or more CoA items has been provided with greater than three decimal places |
| invalidCoaCode | List of invalid CoA items | One or more unrecognised CoA items has been provided, or the CoA item is located in an invalid place |
| invalidFormsSubmissionStatus | None | The trust is not yet setup by the DfE for accepting FMS submissions |
| invalidRequestBody | None | Invalid JSON data provided in request body |
| newFmsSubmissionsClosed | None | The trust has submitted their AR form data to the approval process, so FMS submissions are no longer accepted |
| requestBodyMissing | None | The request body is missing |
| schemaValidation | Dev only | Any JSON schema violation will trigger this error. During development, use of the Enable-Dev-Error-Details=True header will enable schema violation details in the response |
| trustDataNotInBalence | None | Trust data provided within the request must balance |
| unknownAcademy | List of unknown academies | During development, use of the Enable-Dev-Error-Details=True header will enable list of known academies in the response |
| unknownCoaVersion | None | The provided CoA version in not known |
| unknownException | Dev Only | Any exception not covered above. During development, use of the Enable-Dev-Error-Details=True header will display technical error details |
Last updated on