The Eligibility Service is an inbound flow of data from the client to Atlas. The system of record for candidate data and eligibility records are the client's system. The Eligibility Service allows the data to be copied from the client's system into the Atlas platform. The Eligibility API supports full CRUD operations on the synced eligibility record. The Eligibility Service requires that the client's system provide Atlas with information about which candidates are authorized to take which exams. The system allows for passing certain metadata fields that provide instructions on when the candidate is able to see their authorization record, the date range during which the candidate can take the test, information about testing accommodations, demographic information needed by Atlas to administer the program, vouchers and discount coupons, etc. Not all testing programs will utilize all features.
The Eligibility Service has full reference documentation in the API Console tab in the API Store as well as supporting documenation, including examples, in the Documentation tab in the API Store.
In the typical eligibility model, the client system has a mechanism for managing candidates and their eligibility records. It is these records that are passed from the client system to Atlas via the Eligibility Service. The client system typically has a unique identifier for a candidate and for each eligibility record associated with that candidate. The preferred implementation model is for the client system to supply Atlas with the unique identifier generated within the client's system for the candidate AND the unique identifiers generated within the client's system for the eligibility records. An alternate implemenation model uses Atlas to create the candidate identifier and the eligibilty record identifiers. However, this model requires, usually significicant, changes to the client system to store the Atlas generated identifiers so that they can be passed to Atlas on subsequent calls to the Eligiblity Service (for instance, an eligibility update) AND so that event notifications from Atlas can be matched to the correct records in the client system. Implementation complexity and timelines are generally significantly longer for this model. There are many service endpoints, both inbound to Atlas from the client system and outbound from Atlas to the client system that use one or both of these identifiers: a) Eligibility API CRUD operations (from client system) b) Schedule Event Notifications (to client system) c) Test Results (to client system) d) Other specialized APIs and events (from/to client system).
Unless the candidate accesses the Atlas platform via a Single Sign-On (SSO) integration, candidates are expected to know or have ready access to their candidate identifier which must be unique within the program. In addition, the candidate identifiers should be unchanging. If a candidate identifier changes within the client system, the cilent system will need to update all previously transferred eligibility records so that they contain the new candidate identifier. Note that email addresses, GUIDs, auto-incrementing database keys do not make good candidate identifiers. Good examples would be membership numbers, system username based on something other than email address, etc.
Unlike candidate identifiers, candidates are not expected to know their eligibility identifiers. The eligibility records are linked to the candidate identifiers, so once the candidate has been authenticated, the candidate facing systems are able to locate the appropriate eligibility records.
Like candidate identifiers, eligibility identifiers are created by the client system and passed to the Atlas platform through the APIs.