Reference · built on requestConnectorCommerce & orders

PrestaShop

Orders, customers, carts, products, and stock_availables from a PrestaShop 8 shop through the Webservice API.

Request accessPricing ↗

About

PrestaShop is a self-hosted PHP storefront. Its Webservice is a CRUD API at /api/ over the shop's own database: orders, order histories and states, order carriers, customers, carts, products with combinations, and stock_availables. Every resource answers in XML by default or JSON on request, and each API key carries per-resource rights for GET, POST, PUT, PATCH, DELETE, and HEAD.

Through Fibric, an operator polls orders by date_upd, reads the rows and stock behind them, then proposes a status change, a tracking number, or a stock correction. You approve. The connector writes once and leaves a record: what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from PrestaShop and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Orders through GET /api/orders with filter[date_upd], current_state, reference, payment, total_paid, shipping_number, and the order_rows association
  • Order state history through order_histories and the state catalogue through order_states
  • Carriers and tracking per order through order_carriers, payments through order_payments, credit slips through order_slip
  • Customers, addresses, and carts through the customers, addresses, and carts resources
  • Stock per product and combination through stock_availables: quantity, depends_on_stock, out_of_stock, and location
  • Customer service threads and messages through customer_threads and customer_messages

Proposed actions

  • Target capability: propose an order status change through PUT /api/orders/{id}, setting current_state to an order_states id
  • Target capability: propose writing a tracking number to shipping_number on the order
  • Target capability: propose a stock correction through PUT /api/stock_availables/{id}, setting quantity for a product and combination

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Move orders through their states

    New orders arrive by polling. The operator checks payment, totals, and address fields against your rules and proposes a current_state change for those that pass or a flag for those that do not.

    With Order Risk

  • Tracking on every parcel

    When your carrier system issues a tracking number, the operator matches the order by reference and proposes writing shipping_number for your approval.

    With Tracking Sync

  • Forecast stock-outs from stock_availables

    The operator reads quantity per combination and recent order_rows, projects the days of cover, and proposes which products to reorder or to set out_of_stock behaviour on.

    With Stockout Forecast

  • Answer customer threads from the order record

    A customer_threads entry asks about a delivery. The operator reads the order's state history and carrier and drafts a reply from that record for a person to send.

    With WISMO Deflection

Requirements

  • A PrestaShop shop with Enable PrestaShop Webservice set to Yes and its /api/ endpoint reachable from Fibric
  • A Webservice key with GET on orders, order_histories, order_states, customers, carts, products, and stock_availables
  • PUT rights on orders and stock_availables for the proposals above; rights are granted per resource and per method
  • For multistore, the key associated with the right shops and id_shop or id_group_shop passed on requests
Authentication
A 32-character Webservice key created under Advanced Parameters > Webservice, sent as the HTTP Basic username with an empty password.

Limits

  • The Webservice is request and response only. The documentation describes no event push, so order changes are found by polling on date_upd.
  • One key, no password: anyone holding the key has its rights, so keys should carry the minimum resources and methods.
  • Orders reference customers, carriers, and states by id; resolving names takes extra calls or the display=full option.
  • This listing follows the PrestaShop 8 Webservice docs, which PrestaShop marks as outdated in favour of version 9.

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request PrestaShop ↗

Questions and answers

How does a request authenticate?
With HTTP Basic authentication. The Webservice key is the username and there is no password, so the header is Authorization: Basic followed by base64 of the key and a colon. Putting the key in the URL works but exposes it.
Can I get JSON instead of XML?
Yes. Add output_format=JSON to the request. XML remains the default. List calls take display, filter[field], sort, and limit parameters, and schema=synopsis or schema=blank returns the resource's structure.
Does PrestaShop send webhooks?
The PrestaShop 8 Webservice documentation describes no webhook or event push. The connector polls orders and related resources on a schedule, filtering by date_add and date_upd, and reads state changes from order_histories.
Ask about PrestaShop

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with PrestaShop through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy