Operate with Our APIs

To operate with our APIs, it is essential that your business is a registered partner at Falabella and has access to your User ID and API Key, obtained through https://sellercenter.falabella.com/. The details of this process will be explained later.

It is important to note that whether the calls are GET or POST, a response will always be generated, which may vary in detail depending on the requested action, regardless of its success.

These responses can be formatted in either XML or JSON, and this preference can be configured via the input parameters, as appropriate.

How to Obtain Your Credentials?

Access credentials for an already created user in Falabella Seller Center.

As previously mentioned, to operate with our API, you must have access to the API Key. Here's how to do it:

1. Log in to https://sellercenter.falabella.com/ with your Falabella Seller Center username and password.
2. Once inside, click on "My Account."
3. From the dropdown menu, go to "Integrations."
4. You will find the "User ID" and "API Key" in the "API Explorer" section.

Create a new user

The admin must log in to https://sellercenter.falabella.com/ with their Falabella Seller Center username and password.

1. Once inside, click on "My Account."
2. From the dropdown menu, click on "Users."
3. Then click on "Add User."
4. Finally, add details such as email, name, role, among others.
5. For the new user to access the API Key, they must follow the steps in "Access credentials for an already created user in Falabella Seller Center."

Roles and Privileges

Not all users of Falabella Seller Center can call all API methods.

API calls cannot be anonymous. Each call is made on behalf of a specific Falabella Seller Center user, identified by the UserID parameter and authenticated with a corresponding API Key. To make a call to a particular method, the user must have a specific role, detailed as follows.

Request Headers

🚧

Request Headers

All requests must have the User-Agent header set with the following format:

SELLER_ID/TECHNOLOGY_USED/VERSION_OF_TECHNOLOGY_USED/INTEGRATION_TYPE/BUSINESS_UNIT_CODE

SELLER_ID: corresponds to your Seller ID, if you don't remember it, you can find it in Falabella Seller Center under "My Account" or through the "GetSellerByUser" endpoint
TECHNOLOGY_USED: corresponds to the programming language used in the integration
VERSION_OF_TECHNOLOGY_USED: corresponds to the version of the technology used
INTEGRATION_TYPE: this field varies depending on the type of integration:

1. If you are a business integrating directly with Falabella.com: "PROPIA"
2. If you are integrating multiple businesses with Falabella.com: "INTEGRATOR_NAME"

BUSINESS_UNIT_CODE: corresponds to the country code you are integrated with (Chile: FACL; Colombia: FACO; Peru: FAPE)

Are you a business integrating directly with us?

Example: User-Agent: JJJ123/PHP/8.1.7/PROPIA/FACL

Are you an integrator integrating multiple businesses?

Example: User-Agent: JJJ123/PHP/8.1.7/INTEGRATOR_NAME/FACL

More information on this header at MDN - User-Agent.

Additional Request Data through POST

As we've seen, all methods are called through HTTP, some via GET and others via POST.

All calls always take the parameters Action, Timestamp, UserID, Version, and Signature.
Often, additional parameters are added. For example, GetProducts takes additional parameters like the Search parameter.

The following are additional data sent to the ProductUpdate method:

XML

<?xml version="1.0" encoding="UTF-8" ?>
<Request>
  <Product>
   <SellerSku>SKU-AAAA</SellerSku>
   <Price>10.0</Price>
   <SaleStartDate>2015-07-01T11:11:11+0000</SaleStartDate>
   <SaleEndDate>2015-07-01T11:11:11+0000</SaleEndDate>
   <SalePrice>8.0</SalePrice>
  </Product>
  <Product>
   <SellerSku>SKU-BBBB</SellerSku>
   <Price>32.5</Price>
  </Product>
</Request>

📘

GET or POST

The use of GET or POST is specific to the method being called and is indicated in this documentation. Even if it is not necessary to load additional data for a request, you must use POST if that is the specified HTTP command for the method.

📘 Limitations on POST request size

According to the standard web server configuration of SC, the maximum body size for a POST request is 128MB.

📘 Considerations with JSON

When working with JSON, you should always consider parameters as strings, whether defining numbers or booleans, such as:

XMLJSON

<data>
  <PackageHeight>12</PackageHeight>
  <PackageWeight>2</PackageWeight>
  <isMandatory>true</isMandatory>
</data>

{ "PackageHeight": "12",

"PackageWeight": "2",

"isMandatory": "true" }

Results Without Data

Some methods return long XML documents. For example, GetProducts will return a very long XML document, listing each product. The syntax of these responses is explained in detail on the method reference page.

However, several methods do not return data. In those cases, a response is still returned. We call this a SuccessResponse. Depending on the Format parameter passed, it can be in JSON or XML (there are tabs below to view either):

<?xml version="1.0" encoding="UTF-8"?>
<SuccessResponse>
  <Head>
    <RequestId>13e55362-3cc4-446b-b3db-c1df0900ae9e</RequestId>
    <RequestAction>PriceFeed</RequestAction>
    <ResponseType></ResponseType>
    <Timestamp>2015-07-01T11:11:11+0000</Timestamp>
  </Head>
  <Body/>
</SuccessResponse>

{
 "SuccessResponse": {
   "Head": {
     "RequestId": "13e55362-3cc4-446b-b3db-c1df0900ae9e",
     "RequestAction": "PriceFeed",
     "ResponseType": "",
     "Timestamp": "2015-07-01T11:11:11+0000"
   },
   "Body": ""
 }
}

The fields in the section are always the same, regardless of whether a method returns data in the Body section or not. The meaning of the data in a SuccessResponse is as follows:

Similarly, there is an ErrorResponse. It also has a section, which is often empty, but can be used to provide additional information about the error. Below is an example error message that has a body (Body):

<?xml version="1.0" encoding="UTF-8"?>
<ErrorResponse>
  <Head>
    <RequestAction>Price</RequestAction>
    <ErrorType>Sender</ErrorType>
    <ErrorCode>1000</ErrorCode>
    <ErrorMessage>Format Error Detected</ErrorMessage>
  </Head>
  <Body>
    <ErrorDetail>
      <Field>StandardPrice</Field>
      <Message>Field must contain a positive number with a dot as decimal
        separator and 2 decimals (e.g. 120.00)
      </Message>
      <Value>10.0x</Value>
      <SellerSku>Example Seller SKU</SellerSku>
    </ErrorDetail>
  </Body>
</ErrorResponse>

Response:
{
  "ErrorResponse": {
    "Head": {
      "RequestAction": "ProductUpdate",
      "ErrorType": "Platform",
      "ErrorCode": "1000",
      "ErrorMessage": "Could not save product: 0, A exact match of the document is being processed"
    },
    "Body": ""
  }
}

Here too, the fields have a fixed meaning across all methods:

Errors

As described earlier, when an endpoint cannot be executed, an error message is returned that looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<ErrorResponse>
  <Head>
    <RequestAction>GetOrder</RequestAction>
    <ErrorType>Sender</ErrorType>
    <ErrorCode>[number]</ErrorCode>
    <ErrorMessage>E0[number]: [error message]</ErrorMessage>
  </Head>
  <Body/>
</ErrorResponse>

 

Errors are numbered, and error messages are provided.

Global Errors