📘
The better your user journey, the more likely that the applicant will receive an offer from us.

Open API Specification JSON

The OpenAPI Specification (OAS) is a standard, language-agnostic format for defining RESTful APIs, enabling developers to describe the structure of their APIs in a machine-readable format.

Written in JSON, OAS facilitates clear documentation, automatic code generation, and interoperability between tools.

It includes details such as endpoints, HTTP methods, request/response schemas, authentication methods, and more, ensuring consistency and clarity in API development and integration.

You can view or download our Partner API openapi.json specification file from here or the Lead API openapi.json specification file from here (opens in a new tab).

Validation

We currently have relaxed constraints when it comes to user input.

Our philosophy is that if there is bad user data, we will be able to rectify that within our own journey via the provided URL in the endpoint response.

This should be understood as a last resort, ideally the user experience should be a singular journey. Ideally the applicant should be reviewing offers and proceeding to lender platforms when using our platform.

Form

You will notice that our two APIs: unsecured and credit card do not have the same expected payload.

Additionally, there are some fields that require some conditional logic depending on the value inputted by the user. An example of this would be the Current and Previous Address objects that are expected in either API.

But there is also other considerations such as if the applicant is Retired. Naturally in this case we would not expect employment details to be sent in this case, nor an income via employment.

For clarity, it might be worth observing how we collect this data within the demo application, particularly the Current Employment and Other Income stages.

Types

We have exposed our internal types within the demo application. You should use this as a basis of what input you should allow the user.

In the case that it does not conform to our internal types, we will redirect the user to our form so that they can correct their data.

It is important that these types are used so that the quality of the user journey is not diminished.