DocumentaciónAPI ReferenceOpera con Nuestras APIs

Opera con Nuestras APIs

Para operar con nuestras APIs, es fundamental que tu negocio esté registrado como partner en Falabella y que cuentes con tu User ID y API Key, obtenidos a través de https://sellercenter.falabella.com/. Los detalles de este proceso se explicarán más adelante.

Es importante destacar que, ya sean llamadas GET o POST, siempre se generará una respuesta, la cual puede variar en detalle dependiendo de la acción solicitada, independientemente de si fue exitosa o no. Estas respuestas pueden estar en formato XML o JSON, y esta preferencia se puede configurar mediante los parámetros de entrada según corresponda.

¿Cómo obtener tus credenciales?

Credenciales de acceso para un usuario ya creado en Falabella Seller Center. Como se mencionó anteriormente, para operar con nuestra API, necesitas tener acceso a la API Key. Para obtenerla, sigue estos pasos:

●Ingresa a https://sellercenter.falabella.com/ con tu usuario y contraseña de Falabella Seller Center.
●Una vez dentro, haz clic en "Mi cuenta".
●En el menú desplegable, selecciona "Usuarios".
●El correo será tu User ID y tu API Key, estará en la columna de Api Key.

Crear un nuevo usuario

El administrador debe ingresar a https://sellercenter.falabella.com/ con su usuario y contraseña de Falabella Seller Center.

●Una vez dentro, haz clic en "Mi cuenta".
●En el menú desplegable, haz clic en "Usuarios".
●Luego haz clic en "Agregar Usuario".
●Completa los datos como correo electrónico, nombre, rol, entre otros.
●Para que el nuevo usuario pueda acceder a la API Key, debe seguir los pasos descritos en "Credenciales de acceso para un usuario ya creado en Falabella Seller Center".

Roles y privilegios

No todos los usuarios de Falabella Seller Center pueden invocar todos los métodos de la API. Las llamadas a la API no pueden ser anónimas. Cada llamada se realiza en nombre de un usuario específico de Falabella Seller Center, identificado mediante el parámetro UserID y autenticado con su correspondiente API Key. Para poder hacer una llamada a un método en particular, el usuario debe tener un rol específico, según se detalla a continuación.

Roles y Métodos Disponibles

Role	Available Methods
Seller API Access	All
Seller API Product Access	GetProducts, ProductCreate, ProductUpdate, ProductRemove, Image, GetBrands, GetCategoryTree, GetCategoryAttributes, GetAttributes, FeedList, FeedOffsetList, FeedCount, FeedStatus, FeedCancel
Seller API Order Access	GetOrders, GetOrder, GetOrderItems, GetMultipleOrderItems, SetStatusToCanceled, SetStatusToReadyToShip, SetStatustoShipped, SetStatusToFailedDelivered, SetStatusToDelivered, GetFailureReasons, GetShipmentProviders

Headers de la Solicitud

Todas las solicitudes deben incluir el header User-Agent con el siguiente formato: SELLER_ID/TECNOLOGÍA_USADA/VERSIÓN_TECNOLOGÍA/TIPO_INTEGRACIÓN/CÓDIGO_UNIDAD_DE_NEGOCIO • SELLER_ID: corresponde a tu ID de vendedor. Si no lo recuerdas, puedes encontrarlo en el Seller Center de Falabella bajo "Mi cuenta", o consultarlo mediante el endpoint GetSellerByUser. • TECNOLOGÍA_USADA: lenguaje o tecnología utilizada en la integración (por ejemplo, PHP, Node, Python). • VERSIÓN_TECNOLOGÍA: versión de la tecnología utilizada (por ejemplo, 8.1.7). • TIPO_INTEGRACIÓN: varía según el tipo de integración: - Si eres un negocio que se integra directamente con Falabella: PROPIA - Si eres un integrador que conecta múltiples negocios: NOMBRE_DEL_INTEGRADOR • CÓDIGO_UNIDAD_DE_NEGOCIO: código del país con el que te integras: - Chile: FACL - Colombia: FACO - Perú: FAPE Ejemplo de negocio directo: User-Agent: JJJ123/PHP/8.1.7/PROPIA/FACL Ejemplo de integrador: User-Agent: JJJ123/PHP/8.1.7/MYINTEGRATOR/FACL

Datos adicionales en POST

Como hemos visto, todos los métodos se ejecutan vía HTTP, algunos mediante GET y otros mediante POST. Todas las llamadas siempre deben incluir los siguientes parámetros: Action, Timestamp, UserID, Version, y Signature. A menudo se agregan parámetros adicionales según el método. Por ejemplo, el endpoint GetProducts acepta parámetros adicionales como Search. A continuación, se muestra un ejemplo del contenido adicional enviado en el body para el método ProductUpdate:

<?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 o POST

El uso de los métodos GET o POST depende de la acción a ejecutar y está definido en esta documentación. Incluso si no es necesario enviar datos adicionales en la solicitud, se debe usar POST si así lo especifica el método.

Límite de tamaño en solicitudes POST

Según la configuración estándar del servidor de Seller Center, el tamaño máximo del cuerpo de una solicitud POST es de 128MB.

Consideraciones con JSON

Cuando trabajes con JSON, todos los valores deben tratarse como strings, incluyendo números o booleanos. Ejemplo:

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

Resultados sin datos

Algunos métodos devuelven documentos XML extensos. Por ejemplo, GetProducts devuelve un documento XML muy largo con el listado de cada producto. La sintaxis de estas respuestas se explica en detalle en la página de referencia del método correspondiente. Sin embargo, varios métodos no devuelven información en el cuerpo. En estos casos, igualmente se genera una respuesta que llamamos SuccessResponse. Dependiendo del parámetro Format enviado, puede devolverse en formato JSON o XML (puedes ver ambos ejemplos a continuación):

<?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>

Los campos dentro de la sección <Head> siempre son los mismos, independientemente de si el método devuelve datos dentro del <Body> o no. El significado de cada campo en una SuccessResponse es el siguiente:

Campos de SuccessResponse

Name	Type	Description
RequestId	UUID	Unique identifier for this request. Used for tracking through Feeds.
RequestAction	String	Name of the method that was executed (i.e., the value of the Action parameter in the request).
ResponseType	String	Type of response contained in the Body, or empty if there is no content.
Timestamp	DateTime	Moment when the request was executed, in ISO 8601 format.
Body	Subsection	Additional information, described according to the corresponding method documentation.

De forma similar, existe una estructura de respuesta para errores: ErrorResponse. Esta también contiene una sección <Body>, que muchas veces puede estar vacía, pero que puede incluir detalles adicionales sobre el error. A continuación, un ejemplo de mensaje de error con contenido en el cuerpo:

<?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>

Aquí también, los campos tienen un significado fijo en todos los métodos:

Campos de Respuesta de Error

Name	Type	Description
RequestAction	String	The method that caused the error.
ErrorType	String	Source of the error (Sender or Platform).
ErrorCode	Integer	Internal error code (see Errors section).
ErrorMessage	String	Human-readable error message.
ErrorDetail	Subsection	The response may contain these subsections in the Body, providing specific error details. Up to 50 ErrorDetails may be included.

Errores

Como se describió anteriormente, cuando un endpoint no puede ejecutarse, se devuelve un mensaje de error con el siguiente formato:

<?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>

Código	Mensaje
E001	Parameter %s is mandatory
E002	Invalid Version
E003	Timestamp has expired
E004	Invalid Timestamp format
E005	Invalid Request Format
E006	Unexpected internal error
E007	Login failed. Signature mismatching
E008	Invalid Action
E009	Access Denied
E010	Insecure Channel
E011	Request too Big
E030	Empty Request
E429	Too many requests
E1000	Internal Application Error

Introducción Certificando Solicitudes