Skip to content
/
Credit Application Submis...

Direct API Guide

Documentation version 3.01, 20.11.2025

Please note, that the given document is only applicable for partners integrating in Estonia and Latvia.

Inbank API for Partners is designed for integrating third-party applications to Inbank's credit system. The API aims to follow RESTful best practices as closely as possible to achieve its main goal — to be flexible and applicable to multiple use cases. The current document describes the API endpoints available to partners.

For any questions regarding the integration process, contact Inbank at:

Note the partner is responsible for authenticating the customer before the partner transmits customer data to Inbank. Acceptable authentication methods are ID card, Mobile ID or Smart-ID. The partner must be able to prove the customer's authentication to Inbank.

Full integration with Inbank API gives merchants access to the following Inbank products:

Hire Purchase

The Inbank Hire Purchase solution gives customers the opportunity to pay for purchases in installments with an affordable interest rate. Read more about Inbank Hire Purchase on our website.

Split into parts

This payment solution offers clients to buy goods and services and pay for them later in several equal instalments. Split into parts is free of charge for customers, while merchants get paid upfront in full the next working day. Read more about this payment solution on our website.

Flow Overview

API Request Flows in Case of Positive Decision

API Request Flow

*Note that step 6 is only required if the flow is using SMS signing.

API Request Flow with Partner Approval

*Note that step 6 is only required if the flow is using SMS signing.

API Request Flow with Down Payment

API Request Flow with Down Payment and Partner Approval

API Request Flows in Case of income_proof_required Decision

* Note that for all API flows in case of income_proof_required decision with income_proof_type returned as manual_internal_verification, instead of steps 2 and 3 the manual statement upload should be performed. More information can be found here.

API Request Flow

API Request Flow with Partner Approval

API Request Flow with Down Payment

API Request Flow with Down Payment and Partner Approval

Demo Environment

Inbank provides a separate environment for development and integration testing. The testing environment remains available after the integration with Inbank has been completed. The testing and production environments differ, each having individual data sets.

Demo API environment for Estonia: https://demo-api.inbank.ee

Demo API environment for Latvia: https://demo-api.inbank.lv

For testing purposes, the system returns preconfigured decisions. Positive decisions are given for amounts 0 - 500, 15 000 - 16 000.

The credit application process may include an OTP code exchange via SMS. The demo environments do not send out SMS messages. If you are testing the Split into parts payment product, the SMS message is hardcoded to value 0000.

To test the financing products in Estonia and Latvia, you can safely use your own Estonian/Latvian ID-code and ID-card, as the demo environment does not initiate real binding contracts. Alternatively in Estonia, you can use our demo user, the identity code of which is 10101010005. Besides the identity code, you will also need a name and a phone number for authentication and signing.

To use an ID-card or Mobile-ID in the demo environment, you need to register them at:

You can also use Smart-ID by downloading the following apps:

To use Smart-ID for testing, your account level should be Qualified. You can check the account level at https://sid.demo.sk.ee/portal/login.

Credit Contract State Model

Inbank will send callbacks about changes to the credit contract status. Contracts can have the following statuses:



StatusDescription

unsigned

A contract has been created, but has not yet been signed by the customer and/or Inbank.
signed

The contract has been signed by both the customer and Inbank.

For the flow which includes merchant approval, this state indicates that the credit has been granted by Inbank and the system is now awaiting approval from the partner to activate the contract.

activatedThis is the target state: credit contract between customer and Inbank has been activated, merchant is liable for the delivery of goods/services.
cancelled

The credit contract has been cancelled. This state applies only to contracts which previously were unsigned or signed.

For the flow which includes merchant approval, signed contracts get the status cancelled when the merchant has not approved the contract.

terminatedAn existing credit contract has been terminated. This state can only be applied to contracts which previously were activated.

Authentication

Inbank will provide you with an API key, used for authentication, and a unique identifier of your shop, required for building API URLs. The API-key should remain private at all times.

To obtain access to the API endpoints, place the API key in the Authorization header of the request. The Authorization header should have the Bearer scheme and your API key, for example:

Authorization: Bearer e93174d3b9158a01c861c65fab0e7f96

The API server will then verify the API key authenticity.

In most cases, you will need to use a shop identifier (shopUuid) in the path of the API endpoint. Shop identifier is provided to you by Inbank together with the API key.

In case of unsuccessful authorization, the system will return the following message:

{
    "error": [
        "unauthorized"
    ]
}

Content-Type

HTTP header Content-Type application/json is expected in all requests, unless otherwise specified in the endpoint description. Example:

Content-Type: applications/json

Callbacks

When sending a credit application via Inbank Partner API the e-shop has the option to provide the callbackUrl - the URL to which Inbank will send server-to-server callback notifications on financing process status change events. Callback requests are lightweight triggers for initiating activities on the merchant side. They contain only minimal information.

Inbank sends callbacks about the following state transition events:

Status in callback messageDescription
Decision related callbacks
POSITIVEThe credit application received a positive decision and the customer can move forward in the financing process.
NEGATIVEThe credit application received a negative, Inbank cannot offer financing to the customer.
FAILEDThe decision process has encountered issues and the decision cannot be made. If this status persists, please contact the Inbank integration team.
INCOME_PROOF_REQUIREDTo make a decision Inbank needs the customer to provide income proof documents.
Contract related callbacks
UNSIGNEDThe contact has been created and is now waiting for customer signature.
SIGNEDThe customer has signed the credit contract.
ACTIVATEDThe credit contract is now activated, the financing of the purchase has been completed.
CANCELLEDThe contract has been cancelled.
TERMINATEDThe previously activated contract has been terminated.
ACTIVATION_REQUIRES_PARTNER_APPROVALThe financing has been granted by Inbank. Partner's approval is now needed for contract activation. Applicable if the flow requires merchant approval of credit contracts.
DOWN_PAYMENT_PAID_BY_CUSTOMERThe customer has successfully paid the required down payment. Applicable if the flow includes making a down payment.

To avoid processing accidental or malicious traffic to callback endpoints, the handlers should first verify the authenticity of the request. For more details, see the Callback authenticity validation chapter.

E-shop should process the incoming messages, at a minimum, in the following way:

  • Validate the authenticity of the request, to avoid further processing of invalid traffic.
  • Look up the credit application UUID either from the incoming message, or from the internal database as it was returned when the application was sent.
  • Inspect the status message and process the order payment status based on it.
  • Redirect the user to the respective dialog, i.e. the “payment complete” page.

Note in case duplicated callbacks should arrive for a single payment session, please make sure that only the first callback is processed.

Request Structure

Callbacks are sent as http POST requests, ("Content-Type" => "application/x-www-form-urlencoded"). The POST form has the following structure:

ParameterExample valueDescription
message%7B%22type%22%3A%22DECISION%22%2C%22status%22%3A%22POSITIVE
%22%2C%22creditApplicationUuid%22%3A%2259d2194c-634f-4632-91b6-300b58e628ce%22%7D		URL-encoded JSON structure containing information about the financing process.
hmacc196e985640a6291723dc2717d264f82e70126c34b107f3be5b22201cb147c9
8b9709f5184a7f2fe82684d6086eee07df8a46c28fc0edfdd14fd306579244664

HMAC value.

For more details, see HMAC calculation logic described in the Callback authenticity chapter.

timestamp

1549411200

Current Unix timestamp at issuing server.
See https://en.wikipedia.org/wiki/Unix_time for more details.

Request header

{"Content-Type":"application/x-www-form-urlencoded"}

Request body

message=%7B%22type%22%3A%22DECISION%22%2C%22status%22%3A%22INCOME_PROOF_REQUIRED%22%2C%22creditApplicationUuid
%22%3A%22bb3853ce-2034-499e-8b08-42625fdf068b%22%7D&hmac=29087d41b6171ee7598c7789b507429a8227cdf46e68d6f14626f
62ef6d1a5894f3fbdc31c96e885e2dafde7abf24054a8c67a923c58dc86749208abb8a1f721&timestamp=1722587395319

Callback Message Content

The message contains minimal information, it is meant as a trigger to obtaining more detailed information over Partner API. The message body contains:

  • type - type of the Inbank entity the status of which is reflected in the callback. Possible types are CONTRACT and DECISION.
  • creditApplicationUuid - credit application UUID.
  • status - status of the financing process at the moment of message dispatch.

Callback Authenticity Validation

We use message authenticity hash (HMAC) transported within the POST request form field hmac.

To validate the message authenticity you need to calculate the verifying HMAC based on data from the request and your secret api_key, and compare the calculated HMAC with the HMAC value passed in the request.

Verifying HMAC is calculated as SHA512 HMAC, over the timestamp and message from the request, concatenated with . delimiter. Your shop API key is used as HMAC secret.

Pseudocode for example verifying HMAC calculation:

key = your_api_key;
req_timestamp = request[timestamp];
req_message = request[message];
req_data = req_timestamp+'.'+req_message;
v_hmac = hmac(“sha512”, key, req_data);

JavaScript example (Postman):

key = your_api_key;
req_timestamp = decodeURIComponent(request[timestamp]);
req_message = request[message];
req_data = req_timestamp + '.' + req_message;
v_hmac = CryptoJS.HmacSHA512(req_data, key);

PHP example:

$key = $settings->api_key;
$req_timestamp = $_POST['timestamp'];
$req_message = stripslashes($_POST['message']);
$v_hmac = hash_hmac('sha512', $req_timestamp . '.' . $req_message, $key);

API Endpoints

The API endpoints cover all the functionality necessary for full integration with Inbank systems.

Please note: Inbank payment methods should be available only for cart values that are within the price range agreed with Inbank. If you would like to receive the price range and other details of your Inbank product over API, please use the GET /products endpoint.

Languages
Servers
Demo environment
https://demo-api.inbank.ee/
Live environment
https://api.inbank.ee/

Calculations

Operations

Credit Applications

Credit applications are the initial step in the Inbank financing process. Once the application is reviewed and accepted by the customer, a credit contract is created.

Operations

Credit Application Submission

Request

Credit applications are the initial step in the Inbank financing process. Once the application is reviewed and accepted by the customer, a credit contract is created.

POST /partner/v3/shops/:shopUuid/applications

A credit application is submitted using the POST /partner/v3/:shopUuid/applications endpoint. The credit application contains the credit period and amount, identification data and other information regarding the customer and the purchase.

Once the e-shop receives a response to the payment session initiation request with the redirect URL and the UUID of the session, it can forward the data of the credit application to Inbank. To submit credit application data to Inbank, use the POST /partner/v3/shops/:shopUuid/applications request.

Request payload consists of several sub-objects:

  • creditApplication: monthly income, product code and other credit related data
  • customer: customer's identity code, name and gender
  • customerContact: customer's email and phone number
  • customerAddresses: customer's address details
  • customerIdentification: the type of customer identification document and its number
  • consents: customer's consent for processing of their data
  • purchase: details about the purchased items
  • partnerUrls: URL for the callbacks about the process status updates.

Important note for test environments

Document number, phone number and email of one customer cannot be used for another customer. For testing purposes it means that if you introduce a new identity code, you should also generate a new document number, phone number and email address. If you use an existing customer's identity code, you can use both existing and new values for document number, phone number and email address. Due to banking secrecy we cannot indicate the exact reason behind the application failure (e.g. customer with such an email already exists) and will return a generic error: "Error has occurred, contact customer support".

The decisionStatus parameter can have the following values: positive, negative, manual_negative, failed, income_proof_required, pending, manual. It can be considered that the application received a positive decision if its decisionStatus is positive. Usually, a new application has decisionStatus as pending until the decision is reached. To receive the application decision, the GET /application endpoint should be polled once a second for a maximum of 30 seconds.

The decisionMessages contain a list of messages to be displayed to the customer on why the application decision received the corresponding status.

If the response includes the income_proof_required decision status, the customer needs to submit their income proof documents to Inbank.

The new income_proof_type parameter in the response to POST /applications indicates the manner in which the documents need to be submitted, either via the AIS upload process or the manual upload, or via a manual upload only. Possible values are:

  • ais_with_fallback_manual_upload_option - the customer can submit their income proof statement via AIS upload process or manual upload. To perform the AIS upload process, you need to redirect the customer to a third party URL. After the AIS upload process is complete, the customer will be redirected back to the flow on your site.
  • manual_internal_verification - the customer can submit their income proof statement via the manual upload only.

Please note that after the AIS upload process, the application might once again receive the income_proof_required decision status with the manual_internal_verification verification type in cases when Inbank needs additional data from the customer to make a decision.

Security
bearerAuth
Path
shopUuidstringrequired

The unique identifier of the shop.

Example: a93f1f44-d5dd-4469-bfcc-c1de9e969213
Bodyapplication/jsonrequired
creditApplicationobject
customerobject
customerAddressesobject
customerContactobject
customerIdentificationobject
consentsobject
partnerUrlsobject
purchaseobject
curl -i -X POST \
  https://demo-api.inbank.ee/partner/v3/shops/a93f1f44-d5dd-4469-bfcc-c1de9e969213/applications \
  -H 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
  -H 'Content-Type: application/json' \
  -d '{
    "creditApplication": {
      "productCode": "example_product",
      "amount": "2400",
      "period": "12",
      "monthlyIncome": "2900",
      "monthlyFinancialObligations": "100"
    },
    "customer": {
      "identityCode": "38808050001",
      "firstName": "John",
      "lastName": "Smith"
    },
    "customerAddresses": [
      {
        "street": "NIINE",
        "country": "EE",
        "zipCode": "10414"
      }
    ],
    "customerContact": {
      "mobile": "+37253630000",
      "email": "test@test.com"
    },
    "customerIdentification": {
      "documentType": "id_card",
      "documentNumber": "AA979080"
    },
    "consents": [
      {
        "type": "EMTA_REGISTRY_QUERY",
        "value": true,
        "text": "This is EMTA consent"
      }
    ]
  }'

Responses

Create a new application

Bodyapplication/json
uuidstring

Application uuid.

Example: "471e6282-3384-412b-af7b-646eb8f04391"
numbernumber(double)

Application reference number.

Example: 89002917439
statusstring

Session status.

Example: "pending"
productCodestring

Product code.

Example: "example_product"
amountnumber(double)

Financing amount.

Example: 1001
periodinteger(int32)

Financing period in months.

Example: 12
downPaymentAmountnumber(double)

Down payment amount.

Example: 0
paymentDayinteger(int32)

Payment day.

Example: 15
startDatestring(date)

Start date.

Example: "2020-12-15"
endDatestring(date)

End date.

Example: "2021-11-15"
decisionStatusstring

It can be considered that the application received a positive decision if its decisionStatus is positive. Usually, a new application has decisionStatus as pending until the decision is reached. To receive the application decision, the GET /application endpoint should be polled once a second for a maximum of 30 seconds.

Enum"positive""negative""manual_negative""failed""income_proof_requested""pending""manual"
Example: "positive"
decisionMessagesstring

Contain a list of messages to be displayed to the customer on why the application decision received the corresponding status.

Example: "Positive decision"
changedConditionsboolean

Annual credit cost rate.

Example: false
previousUuidstring

Previous uuid.

Example: null
salespersonReferencestring

First name and last name of the sales person as it should appear on reports.

Example: "Earl James"
Response
application/json
{
  "uuid": "471e6282-3384-412b-af7b-646eb8f04391",
  "number": 89002917439,
  "status": "pending",
  "productCode": "example_product",
  "amount": 1001,
  "period": 12,
  "downPaymentAmount": 0,
  "paymentDay": 15,
  "startDate": "2020-12-15",
  "endDate": "2021-11-15",
  "decisionStatus": "positive",
  "decisionMessages": "Positive decision",
  "changedConditions": false,
  "previousUuid": null,
  "salespersonReference": "Earl James"
}

AIS Bank List Retrieval

Request

GET /partner/v3/shops/:shopUuid/account-statements/bank-list?applicationUuid=applicationUuid

In cases when the application receives the income_proof_required decision, the flow needs to include the AIS upload process. The first step is retrieving the list of available banks from which the account statement can be provided via the GET /partner/v3/shops/:shopUuid/account-statements/bank-list API request. The request returns the name, ID and icon URL for each of the available banks. The selection of the banks needs to be displayed to the customer.

Please note that the selection of banks is subject to change.

Security
bearerAuth
Path
shopUuidstringrequired

The unique identifier of the shop.

Example: a93f1f44-d5dd-4469-bfcc-c1de9e969213
Query
applicationUuidstringrequired

The application for which the AIS upload is being initiated. The credit application UUID is included in the response to the POST /application request which submits the credit application to Inbank.

Example: applicationUuid=471e6282-3384-412b-af7b-646eb8f04391
curl -i -X GET \
  'https://demo-api.inbank.ee/partner/v3/shops/a93f1f44-d5dd-4469-bfcc-c1de9e969213/account-statements/bank-list?applicationUuid=471e6282-3384-412b-af7b-646eb8f04391' \
  -H 'Authorization: Bearer <YOUR_TOKEN_HERE>'

Responses

Return bank list by shop UUID & application UUID

Bodyapplication/json
bank_listArray of objects(bankList)
Response
application/json
{
  "bankList": [
    { … },
    { … },
    { … }
  ]
}

AIS Upload Session Initiation

Request

POST /partner/v3/shops/:shopUuid/account-statements/initiate-retrieval

Once the customer selects a bank, the AIS upload session can be started using the POST /api/partner/v3/shops/:shopUuid/account-statements/initiate-retrieval API request. The response includes the redirect URL to which the customer should be forwarded to complete the AIS upload process. Once that process is complete, the customer will be redirected back to your site, to the return URL you have indicated in the request body.

To learn the new decision which the application has received after the AIS upload and processing, the GET /partner/v3/shops/:shopUuid/applications/:applicationUuid endpoint needs to be polled until there is a new decisionStatus. The usual processing time is within 1 working day.

Security
bearerAuth
Path
shopUuidstringrequired

The unique identifier of the shop.

Example: a93f1f44-d5dd-4469-bfcc-c1de9e969213
Bodyapplication/json
applicationUuidstringrequired

The application for which the AIS upload session is being started. The credit application UUID is included in the response to the POST /application request which submits the credit application to Inbank.

Example: "42c939bc-1111-2222-3333-b84fea5b86f6"
returnUrlstringrequired

The URL to which the customer should be redirected back after the AIS upload process is complete.

Example: "https://test.com"
bankIdstringrequired

The ID of the bank selected by the customer for the AIS upload process. The IDs are included in the response to the GET /account-statements/bank-list request.

Example: 24
localestringrequired

The locale which will be used in the AIS upload process. Available options: et, lv, lt, pl, cz, ru.

Example: "en"
curl -i -X POST \
  https://demo-api.inbank.ee/partner/v3/shops/a93f1f44-d5dd-4469-bfcc-c1de9e969213/account-statements/initiate-retrieval \
  -H 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
  -H 'Content-Type: application/json' \
  -d '{
    "applicationUuid": "42c939bc-1111-2222-3333-b84fea5b86f6",
    "returnUrl": "https://test.com",
    "bankId": 24,
    "locale": "en"
  }'

Responses

Upload session

Bodyapplication/json
retrievalIdstring

Retrieval ID.

Example: "b7cfdbc3-1111-2222-3333-6c42b60129b8"
redirectUrlstring

Redirect URL.

Example: "https://ob.nordigen.com/psd2/start/1e2d261a2d9d/SWEDBANK"
Response
application/json
{
  "retrievalId": "b7cfdbc3-1111-2222-3333-6c42b60129b8",
  "redirectUrl": "https://ob.nordigen.com/psd2/start/1e2d261a2d9d/SWEDBANK"
}

Manual Account Statement Upload

Request

POST /partner/v3/shops/:shopUuid/applications/:applicationUuid/attachments

The account statement file can be forwarded to Inbank via the POST /partner/v3/shops/:shopUuid/applications/:applicationUuid/attachments endpoint. If applied, this endpoint needs to be used instead of the AIS upload related endpoints (steps 2 and 3 of the API request flows).

Please note, as income proof documents are processed by Inbank representatives in case of a manual upload, income verification can take some time. To learn the new decision the application has received after the account statement upload and processing, the GET /partner/v3/shops/:shopUuid/applications/:applicationUuid endpoint needs to be polled until there is a new decisionStatus.

Request body parameters:

Attachments must be submitted as form-data.
cURL example: --form "attachments[]=@/path_to/file1.pdf" --form "attachments[]=@/path_to/file2.pdf"

Security
bearerAuth
Path
shopUuidstringrequired

The unique identifier of the shop.

Example: a93f1f44-d5dd-4469-bfcc-c1de9e969213
applicationUuidstringrequired

The unique identifier of the application.

Example: 471e6282-3384-412b-af7b-646eb8f04391
Bodyapplication/json
attachmentsArray of arraysrequired

Files to be added as attachments.

typestringrequired

Type of document. Available option: income_proof_document.

Value"income_proof_document"
descriptionstringrequired

Additional description of the attachments.

Example: "Description here"
curl -i -X POST \
  https://demo-api.inbank.ee/partner/v3/shops/a93f1f44-d5dd-4469-bfcc-c1de9e969213/applications/471e6282-3384-412b-af7b-646eb8f04391/attachments \
  -H 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
  -H 'Content-Type: application/json' \
  -d '{
    "attachments": [],
    "type": "income_proof_document",
    "description": "Description here"
  }'

Responses

Upload session

Response
No content

Application Details

Request

To check whether a credit application received a decision from Inbank and display the credit offer, the partner needs to get the data of the application and credit details using the GET /partner/v3/shops/:shopUuid/applications/:applicationUuid request.

As the decision process might take some time, the endpoint may need to be polled once a second for a maximum of 30 seconds.

The response includes the decisionStatus parameter which can have one of the following values: pending, positive, manual_negative, income_proof_required, negative, failed. It can be considered that the application received a positive decision from Inbank if its decisionStatus is positive. Once the partner receives a positive credit decision from Inbank, it can display the offer to the customer.

Note that there are situations when the application data may be altered by Inbank systems during processing, in that case the application is also assigned a new UUID and the returned application data contains the attribute changedConditions with value true. The changedConditions attribute informs you if the application has undergone changes or not. If you persist Inbank application UUID in your system - you should always compare the returned UUID with the one you requested and update the UUID on your side respectively.

If the response includes the income_proof_required decision status, the customer needs to submit their income proof documents to Inbank.

Note for partners integrating in Estonia

The income_proof_type parameter in the response indicates the manner in which the documents need to be submitted, either via the AIS upload process or the manual upload, or via a manual upload only. Possible values are:

  • ais_with_fallback_manual_upload_option - the customer can submit their income proof statement via AIS upload process or manual upload. To perform the AIS upload process, you need to redirect the customer to a third party URL. After the AIS upload process is complete, the customer will be redirected back to the flow on your site.
  • manual_internal_verification - the customer can submit their income proof statement via the manual upload only.

Please note that after the AIS upload process, the application might once again receive the income_proof_required decision status with the manual_internal_verification verification type in cases when Inbank needs additional data from the customer to make a decision.

Security
bearerAuth
Path
shopUuidstringrequired

The unique identifier of the shop.

Example: a93f1f44-d5dd-4469-bfcc-c1de9e969213
applicationUuidstringrequired

The unique identifier of the application.

Example: 471e6282-3384-412b-af7b-646eb8f04391
Query
typestring
Default "latest"
Enum"latest""initial""exact"
curl -i -X GET \
  'https://demo-api.inbank.ee/partner/v3/shops/a93f1f44-d5dd-4469-bfcc-c1de9e969213/applications/471e6282-3384-412b-af7b-646eb8f04391?type=latest' \
  -H 'Authorization: Bearer <YOUR_TOKEN_HERE>'

Responses

Return application details by shop UUID & application UUID

Bodyapplication/json
productobject
shopobject
creditApplicationobject
purchasestring

Purchase.

Example: null
contractstring

Contract.

Example: null
paymentScheduleobject
Response
application/json
{
  "product": {
    "code": "example_product9",
    "name": "Hire-purchase",
    "subtype": "hire_purchase",
    "type": "loan"
  },
  "shop": {
    "name": "Online testshop",
    "type": "online_partner",
    "uuid": "a93f1f44-d5dd-4469-bfcc-c1de9e969213"
  },
  "creditApplication": {
    "uuid": "471e6282-3384-412b-af7b-646eb8f04391",
    "number": "89002917222",
    "creditApplicationStatus": "pre_request",
    "offerValidTo": "2020-11-15",
    "createdAt": "2020-11-05T13:01:42+02:00",
    "creatorName": null,
    "processStatus": "offer",
    "downPaymentAmountTotal": "0.0",
    "salespersonReference": "Earl James",
    "period": 12,
    "amount": "1001.0",
    "paymentDay": 15,
    "maxLimit": "3000.0",
    "decisionStatus": "positive",
    "decisionMessages": [ … ],
    "downPaymentAmountPrc": null,
    "incomeSource": null,
    "civilStatus": null,
    "housingStatus": null,
    "monthlyIncome": "2900.0",
    "monthlyHouseholdCosts": 0,
    "monthlyFinancialObligations": 0,
    "employerName": null,
    "employerRegistryCode": null,
    "employerPhone": null,
    "employmentStartYear": null,
    "employmentStartMonth": null,
    "employmentEndYear": null,
    "employmentEndMonth": null,
    "dependantsCount": 0,
    "dependantsOver18": null,
    "changedConditions": false,
    "previousUuid": null,
    "confirmedAt": "2020-11-05T13:01:42+02:00"
  },
  "purchase": null,
  "contract": null,
  "paymentSchedule": {
    "period": 12,
    "amount": "1001.0",
    "contractFeeAmountTotal": "11.0",
    "contractFeePrc": "0.011",
    "contractFeeType": "is_paid_according_to_repayment_schedule",
    "creditCostAmountTotal": "157.84",
    "creditCostRateAnnual": "0.301",
    "firstPaymentAmount": "96.57",
    "firstPaymentDate": "2020-12-15",
    "interestRateAnnual": "0.149",
    "lastPaymentAmount": "96.57",
    "lastPaymentDate": "2021-11-15",
    "netCreditAmount": "1001.0",
    "paymentAmountMonthly": "96.57",
    "repaymentsAmountTotal": "1158.84",
    "downPaymentMainPart": "0.0",
    "downPaymentAmountTotal": "0.0",
    "adminFeeAmountMonthly": "0.0",
    "adminFeeAmountTotal": "0.0",
    "insuranceFeeAmountTotal": "0.0",
    "residualAmountTotal": "0.0",
    "residualAmountPrc": "0.0",
    "interestBearingAmount": "1001.0",
    "interestAmountTotal": "146.84",
    "paymentDay": 15
  }
}

Application Approval

Request

POST /partner/v3/shops/:shopUuid/applications/:applicationUuid/accept

After the credit application receives a positive decision and the credit offer is presented to the customer, they can choose to accept the offer, which is done through the POST /partner/v3/shops/:shopUuid/applications/:applicationUuid/accept endpoint. Accepting the application automatically creates a contract and returns the identifier of the contract in the response.

Security
bearerAuth
Path
shopUuidstringrequired

The unique identifier of the shop.

Example: a93f1f44-d5dd-4469-bfcc-c1de9e969213
applicationUuidstringrequired

The unique identifier of the application.

Example: 471e6282-3384-412b-af7b-646eb8f04391
curl -i -X POST \
  https://demo-api.inbank.ee/partner/v3/shops/a93f1f44-d5dd-4469-bfcc-c1de9e969213/applications/471e6282-3384-412b-af7b-646eb8f04391/accept \
  -H 'Authorization: Bearer <YOUR_TOKEN_HERE>'

Responses

Accepts application and creates contract

Bodyapplication/json
contractobject
Response
application/json
{
  "contract": {
    "uuid": "5e3a459a-aada-4d81-b6ad-09cb9483c8bf"
  }
}

Application Cancellation

Request

POST /partner/v3/shops/:shopUuid/applications/:applicationUuid/cancel

After the credit application receives a positive decision and the credit offer is presented to the customer, they can choose to cancel their credit application, which is done through the POST /partner/v3/shops/:shopUuid/applications/:applicationUuid/cancel endpoint.

Security
bearerAuth
Path
shopUuidstringrequired

The unique identifier of the shop.

Example: a93f1f44-d5dd-4469-bfcc-c1de9e969213
applicationUuidstringrequired

The unique identifier of the application.

Example: 471e6282-3384-412b-af7b-646eb8f04391
curl -i -X POST \
  https://demo-api.inbank.ee/partner/v3/shops/a93f1f44-d5dd-4469-bfcc-c1de9e969213/applications/471e6282-3384-412b-af7b-646eb8f04391/cancel \
  -H 'Authorization: Bearer <YOUR_TOKEN_HERE>'

Responses

Cancel application

Response
No content

Credit Contracts

Credit contracts contain the details of the financing agreement between the customer and Inbank. Once the contract is activated, the partner is to supply goods/services to the customer.

Operations