Skip to main content
Netshoes is one of the largest sports and fashion e-commerce groups in Brazil, and runs the Netshoes and Zattini marketplaces. Its marketplace API lets a seller read the orders placed against their store, the products they have listed together with prices, stock and catalogue approval status, and the customer-service tickets raised about their sales.

​
Configuring Netshoes as a Source

In the Sources tab, click on the “Add source” button located on the top right of your screen. Then, select the Netshoes option from the list of connectors. Click Next and you’ll be prompted to add your access.

​
1. Add account access

Netshoes authenticates every request with a pair of credentials: one that identifies the integration and one that identifies your store. Neither expires.
  • Client ID: identifies the integration with Netshoes. Netshoes issues it once the integration passes its technical validation. If you are testing with sandbox credentials, this is the value generated in the Netshoes developer portal under APPS.
  • Access Token: identifies your store. Request it from your Netshoes commercial contact. Sandbox tokens are shown in the developer portal under Tokens Associados.
A sandbox pair can only read sandbox data and a production pair can only read production data. Make sure the pair you paste matches the environment you select below, or every request will be rejected.
  • Environment: production or sandbox. Use production unless Netshoes gave you sandbox credentials for testing.
  • Orders API version: (Default: v1) which version of the Netshoes API your orders are read from. Netshoes documents orders on v1, which is the default. Only switch to v2 if a sync fails saying Netshoes asked your store to migrate.
The following optional settings are also available:
  • Initial sync date: the earliest order date to read on the first sync. Later runs continue from where the previous one stopped. Leave it empty to read your full order history.
  • Seller ID: only needed when the same credentials serve more than one store. The codes available to your credentials are listed in the sellers table.
  • Lookback window: (Default: 7 days) how many days before the last sync the order tables re-read on every run. See Keeping order status up to date below for why this matters.
  • Storefronts: (Default: Netshoes and Zattini) which storefronts to read the department list for. A storefront your store is not listed on is skipped automatically.
  • Page size: (Default: 50) records requested per page. Netshoes caps the order listing at 50.
  • Requests per minute: (Default: 60) how fast this source is allowed to call the API. Netshoes limits how many calls a store may make per minute, and that allowance is shared with every other integration using the same credentials.
  • Base URL: only needed if Netshoes told you to use a different address for your store.
Once you’re done, click Next.

​
2. Select streams

Choose which data streams you want to sync.
The product_prices, product_stocks, product_status and protocol_messages streams read one record at a time — one API call per product, or per service ticket. On a large catalogue they take considerably longer than the others, so only select the ones you need.
Tip: The stream can be found more easily by typing its name.
Select the streams and click Next.

​
3. Configure data streams

Customize how you want your data to appear in your catalog. Select the desired layer where the data will be placed, a folder to organize it inside the layer, a name for each table (which will effectively contain the fetched data) and the type of sync.
  • Layer: choose between the existing layers on your catalog. This is where you will find your new extracted tables as the extraction runs successfully.
  • Folder: a folder can be created inside the selected layer to group all tables being created from this new data source.
  • Table name: we suggest a name, but feel free to customize it. You have the option to add a prefix to all tables at once and make this process faster!
  • Sync Type: you can choose between INCREMENTAL and FULL_TABLE.
    • Incremental: every time the extraction happens, we’ll get only the new data - which is good if, for example, you want to keep every record ever fetched.
    • Full table: every time the extraction happens, we’ll get the current state of the data - which is good if, for example, you don’t want to have deleted data in your catalog.
Once you are done configuring, click Next.

​
4. Configure data source

Describe your data source for easy identification within your organization, not exceeding 140 characters. To define your Trigger, consider how often you want data to be extracted from this source. This decision usually depends on how frequently you need the new table data updated (every day, once a week, or only at specific times). Optionally, you can define some additional settings:
  • Configure Delta Log Retention and determine for how long we should store old states of this table as it gets updated. Read more about this resource here.
  • Determine when to execute an Additional Full Sync. This will complement the incremental data extractions, ensuring that your data is completely synchronized with your source every once in a while.
Once you are ready, click Next to finalize the setup.

​
5. Check your new source

You can view your new source on the Sources page. If needed, manually trigger the source extraction by clicking on the arrow button. Once executed, your data will appear in your Catalog.

​
How orders are organized

A Netshoes order is shipment-centric: the order itself carries the totals and the dates, while the customer, the invoice, the carrier and the products sold all belong to a shipment. One order can hold several shipments, each with its own status. Nekt splits that into four tables you can join:
  • orders — one row per order, with its totals, dates and overall status.
  • order_shippings — one row per shipment, with the recipient, the delivery address, the invoice and the carrier. Join it to orders on orderNumber.
  • order_items — one row per product sold, joined to a shipment by orderNumber and shippingCode.
  • order_devolution_items — one row per product the customer returned or exchanged, joined the same way.
All four are filled from the same extraction, so selecting the detail tables costs no additional API calls.

​
Keeping order status up to date

Netshoes only lets orders be filtered by the date they were placed. An order’s status, however, keeps changing afterwards — it is approved, then invoiced, then shipped, then delivered, sometimes weeks later. That means a plain incremental sync would capture each order once, with whatever status it had at the time, and never see it change again. The lookback window exists to prevent that: on every run the connector re-reads the orders placed in the last few days, so their current status replaces what was stored before. The default of 7 days suits most stores. If your orders regularly take longer than a week to reach the customer, raise it so that deliveries are still within the window when they happen.

​
Things to know

  • Orders and products come from different API versions. Netshoes publishes two APIs: version 1 carries orders, service protocols and the catalogue reference tables, and version 2 carries products, prices and stock. The connector reads each from where it lives, so nothing is required of you beyond the credentials.
  • Catalogue tables change without notice. Netshoes adds and removes brands, colours, sizes and departments on its own schedule, and a product listing is rejected when it names a value that does not exist. The brands, colors, flavors, sizes, departments and product_types tables are re-read in full on every run so they always reflect the current list.
  • Orders fulfilled by Magalu look different. When a shipment’s carrier is “Magalu Entregas - Fulfillment” (carrier code 906), Netshoes advances the order through invoicing, shipping and delivery automatically, and the seller cannot change those statuses. You can identify these shipments by transport_carrierId in order_shippings.
  • Rate limiting is expected on large stores. Netshoes enforces a per-minute call limit and does not publish the number. When it throttles the connection, the sync waits and continues — you’ll see a warning in the run log. If it happens on every run, lower Requests per minute in the source settings.
  • Not every table is available to every store. If your credentials are not allowed to read part of the API, or your store is not listed on one of the storefronts, that table is simply not updated and a warning appears in the run log. The rest of the sync carries on.

​
Available streams

​
Fields by stream