Fruugo Authentication & Database structure

Summary of Changes: (The purpose of this table is to keep traceability and Product team to highlight the things that were changed into the scope, based on comments or discussions)

Fruugo API currently accepts Basic authorization using username/password. Authentication is done at a merchant level. Each merchant who is onboarded will be issued with unique credentials.

We want to store the username and pasword in the Account Fruugo table, however we want the password to be encrypted and not visible in the UI.

Rate limits

Fruugo enforces rate limits on all of its APIs, set to a default of 1000 per minute. Check the "Retry-After" value within the Response header for how to throttle your request. By exception, we have the option to configure this rate limit by merchant.

Errors

The API uses standard HTTP status codes to indicate the success or failure of the API call. For a validation error, the body of the response will be JSON in the following example format:

{
  "type": "field",
  "field": "ProductId",
  "message": "must not be null"
}

For exceeding the rate limit, an example format would be:

{
  "status": 429,
  "reason": "Too Many Requests",
  "method": "GET",
  "path": "/v1/Products"
}

Requests and Responses

Most requests will require an X-Correlation-ID to identify our request.

Parameters and data accompanying your request will be contained in the body of the HTTP request in JSON format.

Web-hooks

For all asynchronous requests that require further queue based processing in Fruugo systems (create/update or get all products/SKUs), we'll initially receive a 202 Accepted response on submission of the request. Once the request is processed, Fruugo will submit a further response to a web-hook endpoint of our choosing for onwards processing in your systems.

This outcome could be a success or error scenario and means no polling for product/SKU statuses is required as we will push a response to you.

We'll be asked to supply Fruugo with our web-hook endpoint URL during integration build.

An example web-hook response body that we will receive in JSON format:

{
"type": "SaveProductResponse",
"payload": {
  "productCreated": true,
  "productUpdated": false,
  "merchantProductId": "papi599VAT",
  "createdSkus": [{
    "merchantSkuId": "papi599_1VAT",
    "merchantSkuQualityStatus": "OK",
    "validationErrors": []
  }],
  "updatedSkus": []
},
"merchantId": 7418,
"correlationId": "c3145570-0731-45db-9c9a-33f97d588400"
}

Along with:

• Timestamp/date
• auth_header
• x-correlation-id
• Body correlationId
• Body merchantId
• Body type

The payload is a MessageEnvelope object containing a payload and type.

The payload will be the json representation of the respecitve response object, for the relevant schema refer to the callback of each request

The type is will be specified in the callback of each request, it is used to differentiate the types of response in the webhook

The correlationId is used to tie the response back to the original request. If we provide a correlation id when making a request, Fruugo will use that and include it in the webhook response. If we don’t provide one, Fruugo will auto-generate one for us, which should be included in the initial response to our request, then it will also be included in the web-hook response. We can then use that to associate the response with the merchant used to make the request, if the merchantId isn’t sufficient on its own.

If there is an internal failure, there will be an attempt to retry the message. If the maximum number of retries has been exceeded, then the webhook response will be an error response taking the format:

{
  "operation": "The type of operation",
  "error": "An error message related to the operation"
}