Retail Services Platform Callbacks
Introduction
This page is intended for informing Retail Services partners about callbacks that we can enable upon their request.
A callback is a request sent to another service when a certain event has happened.
Callbacks are optional, we enable them upon your request on the integration stage.
There are three events in our system that invoke a callback:
Subscription activation
Credentials generation
Subscriber status setting
Subscription activation
We can enable a callback that will let you know when a subscription is activated for a user after they submitted personal data and, if necessary, you confirmed the subscription on your side. It includes an account ID and subscription names together with their end dates.
Preconditions
There is a setting defined for the application which activates a service on sending a callback on subscription activation. This setting defines the event (subscription activation) and the URL to send the callback to.
Trigger
The requested subscription is activated for the user:
The user has provided their personal data
Optional: The subscription is confirmed on your side if you previously required to enable subscription confirmation
Postconditions
The request is sent to you; 200 OK HTTP status is received in the response.
Main course
Steps are as following:
Our system sends the following HTTP POST-request to the URL specified by you:
Header
Content-Type: application/json
Request body
{ "accountId": "<AccountId>", "subscriptions": [ { "feedName": "<FeedName1>", "endDate": <timestamp> }, ... { "feedName": "<FeedNameN>", "endDate": <timestamp> } ] }You application processes the request and send 200 OK in the response.
If your application does not send 200 OK in the response because it is not available at the moment, our system resends the request 4 (four) additional times with 10-sec time interval between two requests until receiving 200 OK in the response or reaching the limit on sending requests.
The response is processed on our side.
Credentials generation
If you have defined that users should log in to your application using credentials (see Questionnaire), we can forward them to a user via email and also send you a callback when they are generated for a new account. It includes an account ID, login, and password.
Preconditions
There is a setting defined for the application which activates a service on sending a callback on credentials generation to the partner. This setting defines the event (credentials generation) and the URL to send the callback to.
You requested that the credentials are generated for the application, and we enabled it in the application settings.
The first subscription is activated for the user.
Trigger
The credentials are generated for the account.
Postconditions
The request is sent to you; 200 OK HTTP status is received in the response.
Main course
Steps are as following:
Our system sends the following HTTP POST-request to the URL specified by you:
Header
Content-Type: application/json
Request body
{ "accountId": "<AccountId>", "login": "<GeneratedLogin>", "password": "<GeneratedPassword>" }Your application processes the request and sends 200 OK in the response.
If your application does not send 200 OK in the response because it is not available at the moment, our system resends the request 4 (four) additional times with 10-sec time interval between two requests until receiving 200 OK in the response or reaching the limit on sending requests.
The response is processed on our side.
Subscriber status setting
We can enable a callback that will let you know when a user chooses their professional status after submitting a personal data form. It includes an account ID and their professional status: PRO or NON_PRO.
Preconditions
There is a setting defined for the application which activates a service on sending a callback on setting subscriber status to the partner. This setting defines the event (setting a subscriber status) and the URL to send the callback to.
The user has defined their subscriber status on the onboarding wizard form and submitted it.
Trigger
The subscriber status is set for an account.
Postconditions
The request is sent to you; 200 OK HTTP status is received in the response.
Main course
Steps are as following:
Our system sends the following HTTP POST-request to the URL specified by you:
Header
Content-Type: application/json
Request body
{ "accountId": "<AccountId>", "subscriberStatus": "<SubscriberStatus>" }Your application processes the request and sends 200 OK in the response.
If your application does not send 200 OK in the response because it is not available at the moment, our system resends the request 4 (four) additional times with 10-sec time interval between two requests until receiving 200 OK in the response or reaching the limit on sending requests.
The response is processed on our side.
Subscription expiration
We can enable a callback that will let you know when user’s subscriptions are to be expired. It includes an account ID and list of subscriptions with their end dates.
Preconditions
There is a setting defined for the application which activates a service on sending a callback on subscription expiration. This setting defines the event (subscription activation) and the URL to send the callback to.
The user has at least one active subscription.
Trigger
There are several possible triggers:
Subscription is canceled via API or the back office.
User has been blocked automatically as a result of the blacklist validation or by a support engineer in the admin panel.
User has been transitioned from non-pro to pro by a support engineer in the admin panel.
Postconditions
The request is sent to the partner; 200 OK HTTP status is received in the response.
Main course
Steps are as following:
Our system sends the following HTTP POST-request to the URL specified by you:
Header
Content-Type: application/jsonRequest body
{ "accountId": "<AccountId>", "subscriptions": [ { "feedName": "<FeedName1>", "endDate": <timestamp> }, ... { "feedName": "<FeedNameN>", "endDate": <timestamp> } ] }Your application processes the request and sends 200 OK in the response.
If your application does not send 200 OK in the response because it is not available at the moment, our system resends the request 4 (four) additional times with 10-sec time interval between two requests until receiving 200 OK in the response or reaching the limit on sending requests.
The response is processed on our side.
Forced subscriber status change
We can enable a callback that will let you know when a support engineer transitions a non-professional user to the professional status as a result of the data clarification process that has proved user’s dishonest identification. It includes an account ID and the subscriber status.
Preconditions
There is a setting defined for the application which activates a service on sending a callback on subscriber status change from non-pro to pro by the support engineer. This setting defines the event (forced subscriber status change) and the URL to send the callback to.
Trigger
Support engineer transitions a user from non-pro to pro in the admin panel.
Postconditions
The request is sent to the partner; 200 OK HTTP status is received in the response.
Main course
Steps are as following:
Our system sends the following HTTP POST-request to the URL specified by you:
Header
Content-Type: application/jsonRequest body
{ "accountId": "<AccountId>", "subscriberStatus": "<SubscriberStatus>" }Your application processes the request and sends 200 OK in the response.
If your application does not send 200 OK in the response because it is not available at the moment, our system resends the request 4 (four) additional times with 10-sec time interval between two requests until receiving 200 OK in the response or reaching the limit on sending requests.
The response is processed on our side.