Integration

Integration refers to the exchange of data between iTEP and external systems. Integration is accomplished by employing APIs and webhooks to make requests to and received data from iTEP. 

Overview

The process of administering a test to a candidate consists of three stages.

Fulfillment

Fulfillment refers to the process of delivering a test id to a candidate. There are multiple methods and process for accomplishing this, and it is the area where the most variability between different Distributors and Local Administrators is found.

Test Administration

Test administration emcompasses all activities relating to the exam itself. These activities include, but are not limited to, accessing the exam, taking the exam, grading the exam, technical difficulties while taking the exam, and exam integrity. iTEP is the sole authority regarding any and all test administration activities. Other than the case of providing a secure and acceptable environment and in-person protoring in a test center scenario Distributors and Local Administrators do have any input or authority regarding these activities.

Results Reporting

Once an exam has been graded and there is no additional review required or technical issues encountered the exam results are reported. The entity that paid for the exam owns the results of the exam and is entitled to direct to whom and by what means the results are reported. There are several common methods of results reporting in use.

Each of the test administration stages are discussed in more detail in the following pages.

Fulfillment

Obtaining a test ID

The first step in the fulfillment process is obtaining a tes ID.

There is always a human-initiated action that launches the process. For some Local Administrators this may be a direct purchase of the test ID by the candidate on itepexam.com. For others it may be part of an HR vetting process or school admission process where the user of a system such as an HR or school admissions system is used by a Local Administrator to indicate that a test id needs to be provisioned for a candidate. Perhaps the candidate initiates the process by applying for a position on a corporate web site, at which time the HR system needs to provision a test ID for the candidate without any additional input. 

In all these cases once the process has been initiated the provisioning of the test ID is automated.

The source of the test ID must first be considered. There are two possible sources. The first, and most common, is that the Local Administrator has an inventory of test ids. In this case an available test ID must be identified in the Local Administrator's inventory. The second is that a sale is created for the test ID at the time of fulfillment.

It is important to note that iTEP's administration system is the final authority with regards to a Local Administrator's available test IDs. iTEP's definition of an available test ID is one that has a status of "Ready". This leads to the first decision that needs to be made regarding fulfillment - where and how is the Local Administrator going to keep track of test ID inventory? At the very least this is needed so that the Local Administrator can determine when additional test IDs need to be purchased. If a large number of test IDs are maintained in inventory all that may be needed is to occasionally check the iTEP administration system. If the test ID inventory is kept at a low level with regard to the usage rate then the Local Administrator must monitor their inventory of test IDs more closely. Most of iTEP's customers use the iTEP administration system to manage test ID inventory. A few have developed systems where the available test IDs are maintained on their system as well as on iTEP's administration system. iTEP's experience is that maintaining a dual inventory system is more challenging to implement and maintain. iTEP currently does not have any APIs directly related to synchronizing inventory. While the are some APIs that a Local Administrator can use to allocate their existing inventory, there is not an API that can be used to automate the procurement of new test IDs, although there are plans to implement some APIs that would be useful for this purpose in the future. The only methods currently available are to manually enter new test ID inventory on your system or use the spreadsheet export on the AVAILABLE TESTS panel in the iTEP administration system to obtain a csv or xls file of your available test IDs, then upload that to your system and reconcile the test ID inventory.

In iTEP's system an Available test ID can be "Assigned" to a candidate. This is accomplished by populating the test field "Assigned-to". When a test ID has data in this field it will not be considered available for use, even though the status of the test is still "Ready" the screen below shows what this looks like in iTEP's administrative system:

In the above example only the test ID 123982B8AP is available to be used. Notice also that the Assigned to information is in JSON format. This is not currently a requirement if executing manual procedures in the iTEP administration system, but is required for API use. The information in the Assigned-to field is completely user-definable, however it is strongly recommended that at a minimum the candidate's name, Email, and some identifying information on your system is included in the event that any troubleshooting needs to be executed.

There are 2 API calls that are commonly used to obtain a test ID. The request body and submission parameters of both calls are the same. The difference between the 2 APIs is one of them assumes you are going to transmit the test ID and instruction to the candidate while the other sends the test ID and test material to the candidate directly from iTEP's administration system.

In order to call an iTEP API you must first generate an API key. This task is performed on the PRODUCT CODE screen of the iTEP Administration system. 

 

(note that the description of integration will necessarily involve referencing other areas of iTEP's technology stack and data.