If your institution has the Aula API enabled, you can use it to manage users, spaces (classrooms or modules), as well as assign roles to users in spaces. Read below for annotated request bodies and some guidance on how to best design workflows with the Aula API.

Our full API spec is available here.

We've designed the API to be modular so that IT teams are able to complete tasks separately and create workflows that best suit the problem at hand.

Spaces can be created one at a time or in bulk, and it's not a requirement for students to be enrolled in them at the time they are created.

User creation also has a separate endpoint.

Once both a space has been created and a user has been created, then users can be granted a role in the space using the /sis/import/roles endpoint.

Creating Users

POST /sis/import/users

{ 
"users": [
{
"firstName": "string",
"lastName": "string",
"externalId": "string", // Unique identifier. This is generally the student ID that is unique to the student across systems
"email": "string",
"sso": boolean, // setting this to false will let the user log in with magic links (one-time password). If empty, it will inherit the default setting for your institution
"custom": // these are optional
{
"studentId": "string", // in case there are multiple student IDs needed
"degreeCourse": "string", // their main degree course
"preEnrollment": boolean, // used to designate stage of enrolment
"internationalStudent": boolean
}
}
]
}

Creating Spaces

POST /sis/import/spaces

{ 
"spaces": [
{
"archived": true, // archived means the space is inactive
"code": "string", // a module code like 7000HUM
"name": "string", // the human-readable name of the space. Most institutions choose to also include semester information.
"externalId": "string" // a unique identifier, used in other calls to the API
}
]
}

POST /sis/import/assessmentitems

{ 
"assessmentItems": [
{
"externalId": "string", // unique externalId of the space
"externalSpaceId": "string", // a unique identifier for the component. Generally this includes semester or cohort codes
"title": "string" // the human-readable title of the assessment item, like 'Final Exam' or 'Lab Report'
}
]
}

Adding users to spaces as either students or educators

Once users and spaces have been added to Aula, you can grant access to those spaces by assigning a role to a user.

POST /sis/import/roles

{ 
"roles": [
{
"role": "student", // or "educator"
"externalUserId": "string", // unique externalId of the student
"externalSpaceId": "string" // unique externalId of the space
}
]
}

Viewing all users in a space

GET /sis/roles/spaces/SPACE_EXTERNALID

This is a mirror of POST operation above

200 Response will include this response body:

{ 
"roles": [
{
"role": "student", // or "educator"
"externalUserId": "string", // unique externalId of the student
"externalSpaceId": "string" // unique externalId of the space
}
]
}

Key points to remember when designing your workflows:

  • Aula grants student or educator roles scoped to a particular space. There is no global educator or student role. This allows Aula to be flexible enough to handle use cases like graduate students, where they may be an educator for one space, but a student in another.
  • Multiple create requests will result in an upsert if any of the fields (updated last name, for example) differ.
  • Aula's API is designed to be idempotent. It's possible to make the same call repeatedly while producing the same result. Specifically, if multiple requests to create or delete an object are sent to the API, they will be processed, and if the intended outcome state is true, they will return 200.
  • Aula's enrolment API has a rate limit of 5 requests per second and a concurrent request rate of 1 to limit race conditions. Each call's request body can accommodate a batch of up to 100 records. We trust that your scripts or other programs have robust error handling, and can use exponential backoff when a 429 is returned.
Did this answer your question?