Applications

This page contains information about managing applications/mandates.

Overview

The Applications API is designed to facilitate the management of Verify by Tiller applications and the individuals associated. It offers the following functionality:

  • Create an application.

  • Retrieve application details.

  • Delete the application (and all associated individuals and check data).

  • Archive the application (to help with record keeping).

The words 'application' and 'mandate' are used interchangeably.

Create application

The Application POST endpoint (/ext/applications) is designed for creating new verification applications. This endpoint initiates the verification process by creating an application and sending email invites to the individuals.

It requires application details, mandate type id (see References section), and information about the individuals. The endpoint ensures that each application is uniquely identified and processed, facilitating a structured and efficient verification workflow.

Example request data:

application_data = {
        "name": "YOUR_APPLICATION_NAME", # A meaningful application name for your business
        "reference": "MANDATE_REFERENCE", # A unique mandate reference
        "mandate_type": 1, # Update ID from references list for your mandate type
        "individuals": [
            {
                "email": "CUSTOMER_EMAIL",
                "title": "Mr", # See references for full list
                "first_name": "FIRST_NAME",
                "middle_name": "", #Optional
                "last_name": "LAST_NAME",
                "date_of_birth": "1980-12-31", #Optional
                "gender": "male",
                "reference": "REFERENCE001" # A unique reference from your system
            } 
            # Additional individuals can be added to this list.
        ]
    }

Retrieve application

The Retrieve Application Endpoint (/ext/applications/{id}) allows you to fetch detailed information about a specific Verify by Tiller application using its unique identifier. This endpoint is useful in actively in monitoring the progress and status of an application, providing comprehensive insights into the progress of the mobile actions, individual checks, status updates, and other relevant data.

Complete application

The Complete Application endpoint (/applications/{app_id}/complete) transitions an application from the "in review" status to "completed." This endpoint is used when the verification process for an application has been fully reviewed, or when it is determined that no further action is needed. Once an application is marked as completed it signifies that the verification process has reached its conclusion.

Reject application

The Reject Application endpoint (/applications/{app_id}/reject) is used to reject an application that is currently "in review." This endpoint plays a crucial role when it is determined that the application does not meet the required standards or the associated checks have failed. By rejecting an application, the system ensures that no further processing occurs and that the application is marked as invalid. This also allows tracking of rejected applications for auditing or reporting purposes.

Delete application

The Delete Application Endpoint (/ext/applications/{id}), accessible via an HTTP DELETE request, enables clients to permanently remove an application using its unique identifier.

This will delete the application and all individual data associated with that application. It ensures clients can efficiently manage their application records, removing those no longer needed or relevant. All applications are automatically deleted after eight weeks as per our privacy policy.

Archive application

The Archive Application Endpoint (/ext/applications/{id}/archive), which is accessed through an HTTP PATCH request, provides a facility to archive an existing application by its unique identifier.

Archiving an application is a prudent way to manage no longer current records but might be needed for future reference. This functionality helps keep the active application pool manageable and relevant while ensuring that historical data is preserved. Archiving differs from deletion in that it preserves the data rather than removing it, allowing for retrieval and review as usual through the retrieve application endpoint.

An archived application will have the following attribute:

"archived": True

Accept check

The Accept Check endpoint (/check/{check_id}/accept) allows the manual acceptance of a verification check. This endpoint is used when a check needs to be marked as manually_accepted. This might occur in situations where the system requires human review before finalising the status of a check. Once a check is accepted, its status is updated, and the relevant data is persisted in the system. The process helps ensure that the system can account for exceptions where automated checks may not fully suffice.

The following body is required in the request:

payload = {
    "comment": "This is a comment for the approval of this check",
    "comment_for": "IndividualCheck",
    "reference": 123456
}

Reject check

The Reject Check endpoint (/check/{check_id}/reject) provides the ability to reject a verification check manually. When a check fails or does not meet the required criteria, it can be flagged as manually_rejected through this endpoint. This ensures that the system maintains an accurate log of rejected checks and can trigger any necessary follow-up actions or notifications. By rejecting a check, administrators can control the verification process and ensure that unsuitable individuals are not processed further.

The following body is required in the request:

payload = {
    "comment": "This is a comment for the rejection of this check",
    "comment_for": "IndividualCheck",
    "reference": 123456
}

Last updated