Create a Verification
DeprecatedCreates a new Verification and return a JSON object representing the newly created Verification.
Verification Processing
Controlling Processing with the Request-Sync
Header
Verifications are generally processed asynchronously: they will be created and returned in the response body without any reports. Truework will then send a webhook when the request has finished processing, and the reports can be retrieved. However, Instant verifications (those which are created without a target company) can also be executed synchronously by using the Request-Sync
header. When processing synchronously, Truework will attempt to process the verification during the initial POST request. If successful, the 201
response will include a reports
key, which will contain the requested data.
This header can take one of the following values. If the header is not defined, the request will default to asynchronous execution.
It is recommended to set a timeout on synchronous requests, to account for potential latency when calling our partners. Synchronous requests generally take only a few seconds to complete, but in rare cases they may take longer.
Synchronous execution is only valid for requests that do not include a target company. Other requests that pass this header will return a 400
response.
Controlling Processing with Request Parameters
Request parameters allow you to configure how you use Truework by selecting only the verification methods and features you need. If the request_parameters
field is left blank, the default
behavior is:
-
If
target.company
is included:- Enable all verification methods
- Set
automated_underwriting_system_eligibility
tonot-required
- Set
employer_filter
totarget-employer
-
If
target.company
is omitted:- Only enable Truework Instant
- Set
automated_underwriting_system_eligibility
tonot-required
- Set
employer_filter
toall-employers
orprevious-employers
Headers
Bearer authentication of the form Bearer <token>, where token is your auth token.
Specify the content type and version that the API should use. It’s recommended to include this to avoid breaking changes.
A header that defines if a request should be executed synchronously. sync
can only return completed or canceled verification responses, not pending. async
will return only pending.
Query parameters
Comma-separated names of fields to include in the response. If omitted, all fields are included
Whether to calculate income analytics for the nested reports in each verification.
Request
A valid purpose is required for Truework to process the verification request.
Throughout the API, this is signified by the permissible_purpose
field.
Information on the individual who is being verified
The verification request use case describes the type of product the verification request is originating from. If omitted, the verifier type in account settings will be used as a default
Any additional information about the target that can help expedite the completion of the verification request
Supporting documentation files provided by the verifier for the verification
The loan id associated with the verification request
A single level key-value JSON object that can be used to store custom data on the verification request; keys and values must be strings
The originating party that requested the verification via a reseller. reseller_originating_party
is required for for companies that resell data provided by Truework.
Response
Verification Request Created.
A valid purpose is required for Truework to process the verification request.
Throughout the API, this is signified by the permissible_purpose
field.
Currently we only support USD as currency. Currency amounts are represented as strings with two decimal precision, e.g. “34.95”.
The state helps convey where the verification request is in the Truework process. It will be returned in the JSON objects returned from this endpoint.
The initial state of all Schemas is pending-approval, and will switch to processing once Truework begins to process the request. However, it may switch back to pending-approval if it is pending approval by the target.
The states completed, canceled, invalid are all terminal states of a Verification. A Report is only available when it is in the completed state. A Verification will enter the state canceled when either Truework or an API user cancels the request. The invalid state indicates that there are issues with the data e.g. we could not locate the employee at a given employer, or could not find the employer itself.
We use data from thousands of verification requests to estimate the duration between creation and completion of a request. For a provided company, upper_bound and lower_bound are the time estimates (in hours) that this particular request will take to be fully processed by Truework. May be an empty if an estimate does not exist for the verification request.
The verification request use case describes the type of product the verification request is originating from. If omitted, the verifier type in account settings will be used as a default
Any additional information about the target that can help expedite the completion of the verification request
The details for the cancellation; only present when state is canceled
The date when this verification was completed in ISO 8601 format
Supporting documentation files provided by the verifier for the verification
The loan id associated with the verification request
A single level key-value JSON object that can be used to store custom data on the verification request; keys and values must be strings
Applicable reports belonging to this request, if the request has been completed
The originating party that requested the verification via a reseller. reseller_originating_party
is required for for companies that resell data provided by Truework.