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.
Direct API Guide
Documentation version 1.02, 25.02.2025
To enhance and unify our APIs, we are updating our endpoints. If you're beginning or planning an integration with Inbank, please note the following changes to ensure compatibility with our latest features and updates. These changes are already reflected in our integration flow, and the documentation will be updated shortly.CamelCase for Parameter Names:
Request body and response parameter names will now use camelCase.
Examples:
product_code → productCode
partner_urls → partnerUrlsHyphens for Request URLs:
Underscores in request URLs will be replaced with hyphens.
Examples:
pos_sessions → pos-sessions
merchant_approval → merchant-approvalv2 Changes to v3 in Request URLs:
Example:
GET /partner/v2/shops/:shop_uuid/contracts/:contract_uuid→GET /partner/v3/shops/:shop-uuid/contracts/:contract-uuid
Please note, that the given document is only applicable for partners integrating in Poland.
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.
If you have any questions regarding Inbank API or have trouble with your integration, just contact integration@inbank.pl and we will be happy to help.
| Environment | API | Partner Portal |
|---|---|---|
| Test | https://demo-api.inbank.pl/partner/v2/ | https://demo-partner.inbank.pl/ |
| Production | https://api.inbank.pl/partner/v2/ | https://partner.inbank.pl/ |
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: https://demo-api.inbank.pl
For testing purposes, the system returns preconfigured decisions. Positive decisions are given for amounts 0 - 500, 15 000 - 16 000.
Note that the credit application process may include an OTP code exchange via SMS. The testing environment does not send out SMS messages, but lists them in the simulator available at: https://demo-sms.inbank.eu/. In the search field at the top of the page, you need to specify the phone number you have indicated in the credit application and click Search. The simulator will then list the messages sent to that number.
Credentials for the SMS simulator:
- username: inbank
- password: XUJc8CncaVKvkEQvNgsTvqdw
* Note that steps 3 and 8 are only required if the flow is using SMS signing.
** Note that steps 10, 11, and 12 are needed if at step 9 you get process_status = waiting_for_customer_digital_verification. If at step 9 you get process_status = activated no further steps are needed.
* Note that steps 3 and 8 are only required if the flow is using SMS signing.
** Note that steps 10, 11 are needed if at step 9 you get process_status = waiting_for_customer_digital_verification. If at step 9 you get process_status = waiting_for_partners_confirmation then proceed to step 13 directly.
* Note that steps 3 and 11 are only required if the flow is using SMS signing.
** Note that if the account statement was uploaded manually and the flow is to include AIS verification then if at step 12 the process_status = waiting_for_customer_digital_verification steps 5 and 6 need to be done after step 12.
* Note that steps 3 and 11 are only required if the flow is using SMS signing.
** Note that if the account statement was uploaded manually and the flow is to include AIS verification then if at step 12 the process_status = waiting_for_customer_digital_verification steps 5 and 6 need to be done after step 12.
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 (shop_uuid) 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"
]
}HTTP header Content-Type application/json is expected in all requests, unless otherwise specified in the endpoint description. Example:
Content-Type: applications/json
When sending a credit application via Inbank Partner API the e-shop has the option to provide the callback_url - 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 message | Description |
|---|---|
| Decision related callbacks | |
| POSITIVE | The credit application received a positive decision and the customer can move forward in the financing process. |
| NEGATIVE | The credit application received a negative, Inbank cannot offer financing to the customer. |
| FAILED | The decision process has encountered issues and the decision cannot be made. If this status persists, please contact the Inbank integration team. |
| INCOME_PROOF_REQUIRED | To make a decision Inbank needs the customer to provide income proof documents. |
| Contract related callbacks | |
| UNSIGNED | The contact has been created and is now waiting for customer signature. |
| SIGNED | The customer has signed the credit contract. |
| ACTIVATED | The credit contract is now activated, the financing of the purchase has been completed. |
| CANCELLED | The contract has been cancelled. |
| TERMINATED | The previously activated contract has been terminated. |
| ACTIVATION_REQUIRES_PARTNER_APPROVAL | The 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_CUSTOMER | The 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.
Callbacks are sent as http POST requests, ("Content-Type" => "application/x-www-form-urlencoded"). The POST form has the following structure:
| Parameter | Example value | Description |
|---|---|---|
| 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. |
| hmac | c196e985640a6291723dc2717d264f82e70126c34b107f3be5b22201cb147c9 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×tamp=1722587395319The 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.
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);Calculations
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.
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/v2/shops/:shop_uuid/applications
A credit application is submitted using the POST /partner/v2/:shop_uuid/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/v2/shops/:shop_uuid/applications request.
Request payload consists of several sub-objects:
credit_application: monthly income, product code and other credit related datacustomer: customer's identity code, name and gendercustomer_contact: customer's email and phone numbercustomer_addresses: customer's address detailscustomer_identification: the type of customer identification document and its numberconsents: customer's consent for processing of their datapurchase: details about the purchased itemspartner_urls: URL for the callbacks about the process status updates.
The table below lists all parameters from the objects within the payload. Parameters can either be required or optional, depending on the integration flow. Please, consult your Inbank contact about your specific case.
The decision_status 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 decision_status is positive. Usually, a new application has decision_status as pending until the decision is reached.
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".
- Demo environmenthttps://demo-api.inbank.pl/partner/v2/shops/{shop_uuid}/applications
- Live environmenthttps://api.inbank.pl/partner/v2/shops/{shop_uuid}/applications
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X POST \
https://demo-api.inbank.pl/partner/v2/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"
}
]
}'Create a new application
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.
Contain a list of messages to be displayed to the customer on why the application decision received the corresponding status.
{ "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" }
Request
POST /partner/v2/shops/:shop_uuid/applications/:application_uuid/signings
After the customer has reviewed the application, they can proceed to application signing which is done via the POST /partner/v2/shops/:shop_uuid/applications/:application_uuid/signings endpoint. There are the following signing methods available:
digital- the method is used in cases when the partner has a separate signing solution. The request with the digital signing method is used as a confirmation that signing has been successful.paper- the method is used if you are collecting paper applications signed by the customer.sms- with this method the signing is done using an SMS code. After you send the request, the customer will receive an SMS with the code from Inbank. After that, the code is sent over to Inbank for confirmation via thePATCH /contracts/:contract_uuid/signingsrequest.
- Demo environmenthttps://demo-api.inbank.pl/partner/v2/shops/{shop_uuid}/applications/{application_uuid}/signings
- Live environmenthttps://api.inbank.pl/partner/v2/shops/{shop_uuid}/applications/{application_uuid}/signings
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X POST \
https://demo-api.inbank.pl/partner/v2/shops/a93f1f44-d5dd-4469-bfcc-c1de9e969213/applications/471e6282-3384-412b-af7b-646eb8f04391/signings \
-H 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
-H 'Content-Type: application/json' \
-d '{
"method": "paper"
}'{ "credit_application": { "uuid": "f4874353-6bb3-4dc8-a25a-3b1c000000000", "number": 89001300000, "confirmed_at": "2019-05-22T14:36:22+02:00" } }
Request
PATCH /partner/v2/shops/:shop_uuid/applications/:application_uuid/signings
To confirm the signing the customer needs to enter the code they received to their mobile from Inbank. The code is sent over to Inbank for confirmation via the PATCH /partner/v2/shops/:shop_uuid/applications/:application_uuid/signings endpoint.
- Demo environmenthttps://demo-api.inbank.pl/partner/v2/shops/{shop_uuid}/applications/{application_uuid}/signings
- Live environmenthttps://api.inbank.pl/partner/v2/shops/{shop_uuid}/applications/{application_uuid}/signings
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X PATCH \
https://demo-api.inbank.pl/partner/v2/shops/a93f1f44-d5dd-4469-bfcc-c1de9e969213/applications/471e6282-3384-412b-af7b-646eb8f04391/signings \
-H 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
-H 'Content-Type: application/json' \
-d '{
"method": "sms",
"confirmation_code": 123456
}'{ "signing": { "uuid": "f4874353-6bb3-4dc8-a25a-3b1c000000000", "number": 89001300000, "signed_at": "2019-05-22T14:36:22+02:00", "method": "sms" } }
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/v2/shops/:shop_uuid/applications/:application_uuid 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 decision_status 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 decision_status is positive. Once the partner receives a positive credit decision from Inbank, it can display the offer to the customer.
If the response includes the income_proof_required decision status, the customer needs to submit their income proof documents to Inbank.
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 changed_conditions with value true. The changed_conditions 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.
- Demo environmenthttps://demo-api.inbank.pl/partner/v2/shops/{shop_uuid}/applications/{application_uuid}
- Live environmenthttps://api.inbank.pl/partner/v2/shops/{shop_uuid}/applications/{application_uuid}
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X GET \
'https://demo-api.inbank.pl/partner/v2/shops/a93f1f44-d5dd-4469-bfcc-c1de9e969213/applications/471e6282-3384-412b-af7b-646eb8f04391?type=latest' \
-H 'Authorization: Bearer <YOUR_TOKEN_HERE>'{ "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 } }
Request
GET /partner/v2/shops/:shop_uuid/account_statements/bank_list?application_uuid=application_uuid
The AIS endpoints are used to submit the income proof statement or for AIS verification of the customer.
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/v2/shops/:shop_uuid/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.
In cases when the customer needs to go through AIS verification these endpoints need to be used after contract signing.
You can find the details of the flows here.
- Demo environmenthttps://demo-api.inbank.pl/partner/v2/shops/{shop_uuid}/account_statements/bank_list/{application_uuid}
- Live environmenthttps://api.inbank.pl/partner/v2/shops/{shop_uuid}/account_statements/bank_list/{application_uuid}
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X GET \
https://demo-api.inbank.pl/partner/v2/shops/a93f1f44-d5dd-4469-bfcc-c1de9e969213/account_statements/bank_list/471e6282-3384-412b-af7b-646eb8f04391 \
-H 'Authorization: Bearer <YOUR_TOKEN_HERE>'{ "bankList": [ { … }, { … }, { … } ] }
Request
POST /partner/v2/shops/:shop_uuid/account_statements/initiate_retrieval
Once the customer selects a bank, the AIS upload session can be started using the POST /api/partner/v2/shops/:shop_uuid/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/v2/shops/:shop_uuid/applications/:application_uuid endpoint needs to be polled until there is a new decision_status. The usual processing time is within 1 working day.
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.
The URL to which the customer should be redirected back after the AIS upload process is complete.
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.
- Demo environmenthttps://demo-api.inbank.pl/partner/v2/shops/{shop_uuid}/account_statements/initiate_retrieval
- Live environmenthttps://api.inbank.pl/partner/v2/shops/{shop_uuid}/account_statements/initiate_retrieval
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X POST \
https://demo-api.inbank.pl/partner/v2/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"
}'{ "retrievalId": "b7cfdbc3-1111-2222-3333-6c42b60129b8", "redirectUrl": "https://ob.nordigen.com/psd2/start/1e2d261a2d9d/SWEDBANK" }
Request
POST /partner/v2/shops/:shop_uuid/applications/:application_uuid/attachments
The account statement file can be forwarded to Inbank via the POST /partner/v2/shops/:shop_uuid/applications/:application_uuid/attachments endpoint. If applied, this endpoint needs to be used instead of the AIS upload related endpoints.
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/v2/shops/:shop_uuid/applications/:application_uuid endpoint needs to be polled until there is a new decision_status.
Request body parameters:
Attachments must be submitted as form-data.
cURL example: --form "attachments[]=@/path_to/file1.pdf" --form "attachments[]=@/path_to/file2.pdf"
Type of document. Available option: income_proof_document.
- Demo environmenthttps://demo-api.inbank.pl/partner/v2/shops/{shop_uuid}/applications/{application_uuid}/attachments
- Live environmenthttps://api.inbank.pl/partner/v2/shops/{shop_uuid}/applications/{application_uuid}/attachments
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X POST \
https://demo-api.inbank.pl/partner/v2/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"
}'Request
POST /partner/v2/shops/:shop_uuid/applications/:application_uuid/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/v2/shops/:shop_uuid/applications/:application_uuid/accept endpoint. Accepting the application automatically creates a contract and returns the identifier of the contract in the response.
- Demo environmenthttps://demo-api.inbank.pl/partner/v2/shops/{shop_uuid}/applications/{application_uuid}/accept
- Live environmenthttps://api.inbank.pl/partner/v2/shops/{shop_uuid}/applications/{application_uuid}/accept
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X POST \
https://demo-api.inbank.pl/partner/v2/shops/a93f1f44-d5dd-4469-bfcc-c1de9e969213/applications/471e6282-3384-412b-af7b-646eb8f04391/accept \
-H 'Authorization: Bearer <YOUR_TOKEN_HERE>'{ "contract": { "uuid": "5e3a459a-aada-4d81-b6ad-09cb9483c8bf" } }
Request
POST /partner/v2/shops/:shop_uuid/applications/:application_uuid/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/v2/shops/:shop_uuid/applications/:application_uuid/cancel endpoint.
- Demo environmenthttps://demo-api.inbank.pl/partner/v2/shops/{shop_uuid}/applications/{application_uuid}/cancel
- Live environmenthttps://api.inbank.pl/partner/v2/shops/{shop_uuid}/applications/{application_uuid}/cancel
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X POST \
https://demo-api.inbank.pl/partner/v2/shops/a93f1f44-d5dd-4469-bfcc-c1de9e969213/applications/471e6282-3384-412b-af7b-646eb8f04391/cancel \
-H 'Authorization: Bearer <YOUR_TOKEN_HERE>'