PrestaShop Webservice: filters, sorting and pagination without downloading the whole catalogue

/api/products works. The next mistake is asking for the whole catalogue with every field on every request.

On a small shop you may not notice. With thousands of products, filtering and pagination become part of the integration design.

1. Do not start with display=full

If a synchronization only needs id, reference, price, active and date_upd, request exactly those fields.

/api/products?display=[id,reference,price,active,date_upd]

2. Filter by reference

/api/products?filter[reference]=[ABC-001]

Useful flow:

EXTERNAL SKU
    ↓
filter[reference]
    ↓
PrestaShop Product ID

3. Stable sorting

/api/products?display=[id,reference,date_upd]&sort=[id_ASC]

or:

sort=[date_upd_DESC]

4. Limits and pagination

limit=0,100
limit=100,100
limit=200,100

Process each batch instead of waiting for the entire catalogue to finish.

5. Batch processing

FETCH
  ↓
VALIDATE
  ↓
TRANSFORM
  ↓
SAVE / SYNC
  ↓
NEXT OFFSET

6. Incremental sync

A better long-term pattern than repeated full exports:

LAST SUCCESSFUL SYNC
        ↓
date_upd
        ↓
ONLY CHANGED PRODUCTS
        ↓
UPDATE TARGET

7. What to log

Track the request URL, offset, limit, HTTP status, records returned, start time and completion time.

8. Empty response is not always an error

It can mean pagination has finished, the filter has no matches, the filter is wrong or you are querying a different shop context.

Production pattern

CONFIG
  ↓
FILTER
  ↓
SELECT FIELDS
  ↓
SORT
  ↓
PAGINATE
  ↓
TRANSFORM
  ↓
STORE
  ↓
VERIFY

The API is not an export button. The goal is to request only what you need, deterministically, in batches you can control.

Next step

Put the paginated read into a Google Sheets reporting workflow, with offsets and sync metadata recorded for every batch. If the request itself is still unclear, return to the first Webservice request guide before automating it.