Getting Started with Atlas APIs Before getting started with the Atlas APIs, the following prerequisites must be met:

1) A fully configured Atlas account configuration. Your account manager will work with you to ensure your Atlas account is properly configured. Depending on the specifics of your integration "fully configured" means different things. At a minimum, tour account management team must ensure that your tests have been registered with the scheduling engine.

2) You need to have access to the API environment. Your technical account manager will work with you on setting up the access. This includes setting up your access credentials to the API Store; ensuring proper connectivity between the development environments; etc.

The API Store is a Web application which hosts our published APIs. It provides a structured GUI, designed for API consumers and partners to self-register to find, explore, subscribe to and evaluate available resources. PSI uses the WSO2 API Manager to manage the APIs and expose them to API consumers.

All API endpoints are secured with TLS.

Defining an Application and Subscribing to an API

Your first steps will be to login to the API Store using the credentials provided by your technical account manager and create an application and subscribe to the specific APIs you'll be accessing as part of the integrated solution.

See https://docs.wso2.com/display/AM1100/Subscribe+to+an+API for a WSO2-provided tutorial.

API Console

The API Store provides an integrated API Console for viewing the API documentation as well as invoking API calls.

See https://docs.wso2.com/display/AM1100/Invoke+an+API+using+the+Integrated+API+Console for a WSO2-provided tutorial.

Swagger

The Atlas APIs are defined in Swagger. The API Console provides a download link for the swagger.json file. PSI uses the swagger codegen project to create the client code we use for interacting with the Atlas APIs. It supports a multitude of different languages currently and is worth investigating. It’s not mandatory but can help simplify and speed up implantation on your end.

https://github.com/swagger-api/swagger-codegen

3) API Authentication

The API Manager provides the token service used to secure the API endpoints. has a security component where a token needs to be retrieved from a token service initially then sent to our API endpoints for authorization. I’ve attached some documentation that shows the sequence diagram for the token generation process.

See: https://docs.wso2.com/display/AM1100/Working+with+Access+Tokens

4) Eligibility API

The attached “PSI Candidate Rest Eligibility Service” document provides the currently designed calls for sending, updating, canceling and retrieving candidate eligibility records.

Note: Much of the attached documentation was prepared for internal consumption. There has been some refactoring to make it more useful for external consumers. The JSON models in the attached document are not defined as clearly as we would like. We welcome your feedback on how we can improve this documentation.

A sample minimal eligibility JSON object with reasonable accommodations (full models are in attached html document and on the API Manager Store) that would be a POST looks like this:

POST /accounts/{account_code}/candidates

{ "candidate": { "candidate_id": "123456", "first_name": "Jane", "last_name": "Smith", "email": "jsmit@example.com", "special_accommodations": [ ] }, "client_eligibility_id": "2016081502041234561", "test_code": "ACTWAM", "schedule_start_date": "2017-10-01T00:00:00+00:00", "eligibility_end_date": "2017-12-20T00:00:00+00:00" }

General Notes:

The candidate_id is the unique identifier for the candidate in the originating system.

The client_eligibility_id is the unique identifier for the eligibility record in the originating system.

The test_code is the unique identifier for the test in the originating system.

The JSON object must be encoded in UTF-8. All date fields must follow ISO-8601 formats (https://en.wikipedia.org/wiki/ISO_8601).

Note: We are currently in the process of redesigning the eligibility API so that you no longer will need to pass your account code as a path component. We expect this to happen in the next few weeks. We will want to migrate your implementation to this new version. We strongly recommend use of the swagger codegen project to generate your client code to minimize the impact of this impending change.