Tesco Authentication, Database Structure & Limits

Authentication

API Docs : https://api.marketplacer.com/docs/seller-api/overview/

There are two possible scenarios in authentication on Tesco:

• The first one is a simple, bearer token sent as an Authorization header with every call. After testing, we found out that we need to include the MARKETPLACER-API-KEY header with this type ot authentication as well.
• The second one is when the Tesco instance (i.e the actual Marketplace) is password protected via Basic Authentication, we will not be able to supply an API key and a username/password using an Authorization header. Instead we need to set the username/password using the Authorization header (select the Basic Authentication scheme) and set the API key as  MARKETPLACER-API-KEY header

Both are possible and it is strongly dependant on the individual marketplace that we are connecting to. We need to be prepared for both scenarios so we need to have two radio button fields in Account Tesco indicating what is the auth type. Suggested names for the buttons are Bearer Token Auth and Basic Auth

Marketplacer emposes an API key rotation policy so we need to be able to see the current API key and update it from the UI when rotated. The rotation is done manually in Marketplacer.

Database Structure

We will need the standard tables such as Channel Tesco Order Tesco and Listings Tesco. The Order Tesco and Listings Tesco will not be added here, instead in the other parts of the scope wherever needed, the tables and the new fields will be specified.

Channel Tesco : This is our starting point and this table will keep the integration/marketplacer settings.

Once Bearer Token Auth is clicked, it should pop a new field named “Token”. Explanation below. Once Basic Auth is clicked, it should pop new fields named Username, Password and API Key.The radio button should be one field with two radio options and based on the selection to show/hide up the Token or username/password fields | N/A | | Token | varchar | Conditional | To be shown only when radio button “Bearer Token Auth” is clicked. | N/A | | Username | varchar | Conditional | To be shown only when radio button “Basic Auth” is clicked. | N/A | | Password | varchar | Conditional | To be shown only when radio button “Basic Auth” is clicked. | N/A | | API Key | varchar | Yes | To be shown when the auth type radio button is clicked (regardless which option) | N/A | | Default Courier | enum dropdown | No | This should be a dropdown menu with all the available couriers from the get couriers query , more info Get Couriers. We should display the Name but send the ID | N/A | | Cancel Action Default | dropdown | No | Should have two options : Accept and Reject. More info here Per account we can set by default to Accept or Reject refund; In Account Tesco table we need to add additional options which will be Cancel Action Default and Return Action Default which will work as a default action if we would like to automatically accept or reject all claims for the specific account. If is “Accept“ , by default we accept the refund, if is “Reject“ , by default we reject the refund. | | | Refund Action Default | dropdown | No | Should have two options : Accept and Reject. More info here Per account we can set by default to Accept or Reject refund; In Account Tesco table we need to add additional options which will be Cancel Action Default and Return Action Default which will work as a default action if we would like to automatically accept or reject all claims for the specific account. If is “Accept“ , by default we accept the refund, if is “Reject“ , by default we reject the refund. | |

Limits

Paging result sets should be employed as a matter of best practice irrespective of the expected result set size.

A maximum page size of 500 is recommended for all GraphQL APIs.

In order to specify the page size, we need to include with every query parameters of first and after. We also want to include the pageInfo object with hasNextPage and endCursor fields. hasNextPage will have either a true or false statement and by this we will understand if there are more pages. If there are more pages ( hasNextPage = true), we need to know how to get to the next page, we do this by specifying endCursor in pageInfo . We can then “request” this page of data the next time we make a request.

The first parameter will display the number of results that we want to get - for example if we select first : 10 , this will return up to 10 objects of the requested info. The after parameter is used to request the data for the next page using the endCursor .

We want to use the first and after as variables as we want to set different page sizes for the different queries. The variables will be specified per each query.

An example would be :

query ExampleQuery($pageSize: Int, $endCursor: String){
  taxons(first: $pageSize, after: $endCursor ) {
    totalCount
    pageInfo {
      endCursor
      hasNextPage
     }

Other information

All of our calls must contain a Content-Type header of application/json