This is a new service - your feedback (opens in a new tab) will help us to improve it.

  1. Home
  2. APIs
  3. AttendanceApi_V1

Attendance Api

Lifecycle stageLive
Open API fileView Open API file
Supported Authorisation types
  • Application Restricted
  1. Overview
  2. Versioning
  3. API browser and Swagger file
  4. Authentication
  5. HTTP status codes
  6. Request Rate Limits
  7. Endpoints

Overview

We developed the attendance API to allow schools to submit attendance data. MIS software developers can use the API to connect with the DfE Developer Hub and submit summarised attendance data for a school. The connection is secure and the endpoint is restricted.

Versioning

When an API changes, we will make backwards compatible changes where we can. When this is not possible, we will add a note about deprecated endpoints and make a new endpoint available.

API browser and Swagger file

For more detailed information on each API action, open the API browser and look at the API Swagger file.

You can also generate a client library from the Swagger file using the Swagger editor.

This project uses the OpenAPI 3.0 specification so Swagger tools used need to support this specification.

Authentication

To use the DfE Attendance API, you will need authentication.

  1. Register an application on the Developer Hub.
  2. Ask to subscribe to the Attendance API.
  3. When your subscription request has been approved, use your client ID and secrets to start the OAuth client credential flow.
  4. Send the JWT token (JSON Web Token) and API subscription key in the header to call the API.

HTTP status codes

The DfE Attendance API uses standard HTTP response code conventions:

  • 100 codes give information
  • 200 codes mean success
  • 300 codes mean redirection
  • 400 codes mean a client-side error
  • 500 codes mean a server-side error

Common status codes are:

  • 200 - OK - the request has been processed successfully
  • 201 - Created - the Created success status response code indicates that the request has succeeded and has led to the creation of a resource (used for post requests with no errors)
  • 202 - Accepted - the Accepted response status code indicates that the request has been accepted for processing, but the processing has not been completed (used for post requests with some errors)
  • 400 - Bad Request - the incoming request body or parameters do not conform with the OpenAPI or Swagger document that describes the API (can include a message to indicate the problem in the requested payload - for example, Unexpected URN)
  • 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 reason
  • 429 - Too Many Requests - the client’s limit has been exceeded
  • 503 - Service Unavailable - the service is currently unavailable
  • 504 - Gateway Timeout - there is a network connection problem within the layers of the API fulfilment stack

We use HTTP status codes instead of API error codes.

Request Rate Limits

We limit how many API requests you can make each minute.

If you go over the limit, you will receive a 429 Too Many Requests HTTP status code for each request you make within the remainder of the time.

For example, in each minute, you can make up to 1000 requests for each endpoint for the same API client or IP address.

The limit is not fixed and we might change it after talking with the API client developer.

Endpoints

/attendances
POST
/provider/{URN}
GET
/codes/attendance
GET
/codes/ncyeargroup
GET