- Deborah Cross (Unlicensed) to resolve whether to edit and/or link content
| Table of Contents |
|---|
Purpose of the API
The Audit Service API is designed to provide a method of programmatically pulling down the audit logs that are visible within the Admin web pages.
...
- A greenID account must be established. This includes specifying the rules to be used, the data sources that will be available, and a range of other configuration options.
- Get the Web Service credentials. These consist of an "account ID" and a Web Service password. These must be obtained from greenID, and used in every Web Service call.
- Consume the WSDL.
GreenID offers two separate environments: test and production. Customers start out in test, where they may carry out their development activities, performing as many test verifications as they like. Once the customer is satisfied with their integration, their account can be activated in the production environment.
How to Use the API
The API has only one method:
retrieveAuditLogs - this method returns the audit logs for a particular verification attempt. All logs related to the specified validation attempt, including calls to external data sources, and any admin activity is returned.
...
See Web Service Endpoints for WSDL details.
API Parameters
A successful audit log request call looks like the following:
| Code Block |
|---|
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ser="http://services.registrations.edentiti.com/">
<soapenv:Header/>
<soapenv:Body>
<ser:retrieveAuditLogs>
<accountId>account_id</accountId>
<password>password</password>
<verificationId>pUz9rXAc</verificationId>
</ser:retrieveAuditLogs>
</soapenv:Body>
</soapenv:Envelope> |
...
Possible "webservice" Sub Codes
The sub code for in the webservice logs are contains the methods method name called in the web service. These include:
- registerUser
- registerVerification
- getVerificationResult
- getOneTimeSessionToken
- isUserIdRegistered
Examples are registerVerification and getVerificationResult.
Event Statuses
This field will tell you whether the logged event was successful or not. There are a number of different possible results . For "customer" event type "datasourceattempt" events, the following statuses apply:
- VERIFIED - Success.
- VERIFIED_ADMIN - Verified after admin changes.
- VERIFIED_WITH_CHANGES - Verified with some changes.
- FAILED - Check has failed.
- IN_PROGRESS - User has still not passed that check, indicating that the attempt logged by this log event failed.
- ERROR - Site returned an error, so could not perform check.
- PENDING - Verified from site, but with changed data. Waiting for an admin to approve it.
For background checks, or "system" checks, the following statuses apply:
- AUTOFAIL - Failed an automatic check.
- FAILED - Failed a check.
- NOT_FOUND_ON_LIST - Used for watchlists, could not find the person on the list.
- FOUND_ON_LIST - Used for watchlists, could find the person on the list.
- PASSED - Passed a check.
- ERROR - Site returned an error, so could not perform check.
Other logged events may have a status as well, that will include events in the above lists. An example of that is the "statechange" log event, which can contain the same event statuses as the customer datasourceattempt logs.- refer to the Individual Source States reference table.