About the Surpass API v2
The Surpass API v2 is a REST API: it is client-server based, stateless, layered, uses HTTP requests to send and retrieve data, has a uniform interface (read Using the Surpass API v2 test console), and data accessed can be cached.
Our APIs let you automate how you interact with Surpass. For example, the methods we have available allow an external system to synchronise its candidate, centre, and test session records, or extract important result and reporting data.
Surpass is a .NET MVC application; the Surpass API does not absolutely reflect the Surpass UI, but the majority of the Surpass Platform’s functionality and settings found in the Surpass UI are represented in the API.
In this section
Integrating with the Surpass API v2
Integrating with the Surpass API offers many benefits, including the ability to:
- Send and retrieve data whenever you want, meaning you are not restricted to specific time periods.
- Automate your internal processes so that only one master system has to be updated, removing administrative overhead.
- Bulk migrate candidate, centre, and test scheduling records to avoid manual input into the Surpass Platform.
- Provide certification and statistical analysis externally by extracting all results and reporting information.
- Diagnose any issues using common HTTP errors (401…), simplifying integrations.
- Not be tied to a particular server, enabling a more scalable integration from which you can easily recover from failed requests.
Surpass Platform entities
Before using the Surpass API, it is beneficial to have an understanding of the way Surpass works and how the entities all relate to one another. The core Surpass entities are centres, candidates, subjects, and users.
Pre-delivery
The following data model demonstrates the different entities required for the set up of tests prior to delivery and their relationship to one another in the Surpass Platform:
Delivery and post-delivery
The following data model demonstrates the different entities required for test delivery and their relationship to one another in the Surpass Platform:
Test Administration workflow
Test sessions move through different states during the Test Administration workflow, starting with being scheduled and ending with being archived in the Audit warehouse. For information on how you can interact with test sessions at different states using the Surpass API, read the Test Administration API reference documentation.
The following state workflow diagram details each state a test can pass through on its journey through the system:
Each test session state is identified by a state number and state name. The following table contains a description of every test session state and in which screen of Surpass it is related to:
State No. | State Name | Description | Surpass UI Screen |
---|---|---|---|
1 |
ScheduledButNotCreated |
The test has been scheduled, but its content not yet retrieved. |
Schedule |
2 |
ScheduledButNotDownloaded |
The Pre-session Download Window has opened but the test has not yet been downloaded.
NOTE: This is a temporary state between the test session being ScheduledButNotCreated and ScheduledButLocked.
|
Invigilate |
3 |
ScheduledButLocked |
The test form has been generated. Test form content and settings (including item content) are locked once generated and cannot be edited for the scheduled test session. Test sessions remain locked until the test window opens. |
Invigilate |
4 |
Ready |
The test window is open and the test is ready to be sat by the candidate. |
Invigilate |
5 |
LockedForInvigilator |
The invigilator needs to manually unlock the test session. |
Invigilate |
6 |
InProgress |
The test session is in progress. | Invigilate |
7 |
Paused |
The test session has been paused by an invigilator. |
Invigilate |
8 |
Offline |
NOTE: This is a retired state.
|
N/A |
9 |
Finished |
The test session is finished.
NOTE: This is a temporary state between the candidate finishing their test and their script moving through to either AwaitingMarking or Archived.
|
Invigilate |
10 |
Voided |
The test session has been voided. |
Invigilate |
11 |
Marked |
The candidate’s script has been marked.
NOTE: This is a temporary state between marking being finished and the script moving through to either Moderate (AwaitingVerification) or Audit (Archived).
|
Mark |
12 |
ScriptVerified |
The candidate’s script is being submitted.
NOTE: This is a temporary state between the script becoming Archived after being released from Mark (AwaitingMarking), or to Moderate (AwaitingVerification) from Mark.
|
Moderate |
13 |
Archived |
The test session is warehoused in Audit. |
Audit |
14 |
LockedByPin |
The test session is awaiting the candidate to enter the session’s PIN. |
Invigilate |
15 |
AwaitingMarking |
The candidate’s script is waiting to be marked. |
Mark |
16 |
AwaitingVerification |
The candidate’s script is waiting to be moderated. |
Moderate |
17 | N/A |
The test session was delivered on paper and the candidate’s results uploaded using Upload OMR Results. OMR uploaded scripts are automatically warehoused (Archived). |
Audit |
18 |
AwaitingUpload |
The test session was downloaded to SecureClient but has not yet been uploaded back into Surpass. |
Invigilate |
19 |
PaperResponseUpload |
The test session is being delivered on paper and the candidate’s results are yet to be uploaded. |
Invigilate |
99 |
Exception |
The test has failed to move between states and a manual intervention by the Surpass support team is required. |
N/A |
Further reading
Now you know what the Surpass API v2 is, read the following articles to learn more: