PrestaShop and Zapier: automating workflows without writing code

Last reviewed June 2026. Zapier's directory and PrestaShop JSON support change over time, verify both for your version before you rule anything out. Back-office paths verified against PrestaShop 1.6, 1.7, 8.x and 9.x.

"Without writing code" is the promise that draws most merchants to Zapier, and it is broadly true, but there is one fact about PrestaShop that nobody tells you up front: at the time of writing, there is no PrestaShop-maintained app in Zapier's directory. Search Zapier for "PrestaShop" and you will not find the clean Shopify-style connector you were expecting (verify Zapier's directory for any current third-party options before you rule it out). That does not mean the no-code path is closed. It means the direct no-code path usually runs through PrestaShop's built-in Webservice API and Zapier's generic Webhooks step, with third-party connector modules or middleware as the other route, and knowing exactly how those two pieces fit together is the whole game. This guide walks the actual no-code wiring on a real PrestaShop back office, where it genuinely needs zero code, and the two or three places where someone quietly hands you a snippet and calls it "no-code" anyway.

If you are still deciding which platform to standardise on, or you want the broad catalogue of store operations worth automating, start with our companion piece, Zapier and Make for PrestaShop, and come back here for the hands-on connection mechanics.

Why there is no "PrestaShop app", and why that is fine

Hosted platforms like Shopify publish and maintain a Zapier app because there is one company controlling one codebase. PrestaShop is self-hosted and open-source: your store lives on your server, on your version (1.6, 1.7, 8.x, 9.x), with your modules. There is no central party to publish and certify a single connector against all of that. So instead of a branded app, PrestaShop exposes a Webservice API, a standard REST interface built into the core, and Zapier talks to it the same way it talks to any custom API: through generic Webhooks by Zapier steps. Once you accept that, the "no native app" problem turns into a fifteen-minute setup, not a dead end.

Step 1. Turn on the Webservice (genuinely no code)

This is the foundation and it is pure back-office clicking:

• Go to Advanced Parameters → Webservice (in PrestaShop 1.6 it lives under Advanced Parameters → Web service).
• Set Enable PrestaShop's webservice to Yes and save.
• Click Add new webservice key. PrestaShop generates a long random key. This is the credential Zapier will use, so treat it like a password.
• In the permissions grid, grant only the resources you actually need. For reading orders, tick orders (and usually customers, addresses) under View (GET). For writing back. Say, updating stock. Tick stock_availables under Modify (PUT). Leave everything else off.

So what does this buy you? A scoped key that can do exactly one job and nothing else. If that key ever leaks, the blast radius is whatever you ticked, not your whole database. One real gotcha that catches people on shared or older hosting: the Webservice needs URL rewriting working. If you enable it and calls 404, check that Shop Parameters → Traffic & SEO → Friendly URL is on and that your server actually rewrites; some Apache setups need mod_rewrite enabled and PrestaShop's generated .htaccess rewrite rules in place (the rules that route /api to the Webservice dispatcher). That is a server setting, not code you write.

Step 2, choose your direction: store-to-Zapier or Zapier-to-store

Every automation runs one of two ways, and PrestaShop handles them very differently. Getting this distinction right is what separates a setup that works from one that silently misses orders.

Step 3, the trigger direction (where "real-time" hides a catch)

You want a Zap that fires when a new order lands. There are two honest ways to do it, and they have very different feels.

The pure no-code way: scheduled polling

Use a Schedule by Zapier trigger (say, every 15 minutes) followed by a Webhooks by Zapier → GET step that calls your orders endpoint:

• URL: https://yourstore.com/api/orders?display=full&sort=[id_DESC]&limit=5&output_format=JSON
• Authentication: Basic Auth, username = your Webservice key, password = left blank.

That display=full parameter matters as much as the rest of the URL: without it the Webservice returns only resource references (a list of IDs), not the order fields you want to map, so you either add display=full or do a two-step fetch (list IDs, then GET each order by id). The output_format=JSON parameter is the other key piece, by default the Webservice returns XML, and JSON output depends on your PrestaShop version supporting it, so confirm your store actually honours it. Polling like this also needs dedupe logic: store the last seen order id or date and only act on rows newer than that, otherwise you will reprocess the same orders every run or miss a burst that arrives between polls. The other trade-off: polling is not instant (you wait up to your interval) and it costs a task every run whether or not there is a new order. For most small-to-medium stores that is a fair price for zero developer involvement. This is the route we recommend you start on.

The real-time way: a webhook from your store

If you genuinely need an order to hit Zapier the instant it is placed, the store has to push. Core PrestaShop does not send outbound webhooks on its own, so this means installing a webhooks module that fires an HTTP POST on events like order creation (internally hooking actionValidateOrder or actionOrderStatusPostUpdate) to a Catch Hook URL that Zapier gives you. The good news: a well-built webhook module is configured entirely from the back office, you paste Zapier's catch URL into a field and pick which events to send. No code. The honest caveat: you are now depending on a module to be on the right side of every PrestaShop and PHP version you run, which is exactly the kind of compatibility headache we obsess over so you do not have to.

Step 4, the action direction (the "no-code" asterisk)

Writing back into PrestaShop is where the no-code promise gets its asterisk. The Webservice accepts changes as XML, not the friendly form fields Zapier shows for native apps. To update a product's stock, the correct flow is: GET the exact stock_available row for that product (matching the right id_product_attribute for combinations and the correct shop context in multi-shop), change the <quantity> value, then PUT the whole XML block back with every required field preserved. This is easy to corrupt: PUT replaces the whole resource, so dropping or mismatching a field, the combination id, the shop id, a dependency. Can write the wrong stock or break the row. Always test this on a staging copy before pointing it at your live store. In a Webhooks by Zapier step you are pasting an XML template and dropping mapped fields into it. It is not programming. There are no loops, variables or logic, but it is more than dragging blocks, and an honest guide should say so rather than pretend the whole thing is point-and-click.

The XML body for that stock PUT, with the fields PrestaShop expects preserved, looks like this. Note that you GET the row first to learn the real ids, then change only <quantity>:

<?xml version="1.0" encoding="UTF-8"?>
<prestashop xmlns:xlink="http://www.w3.org/1999/xlink">
  <stock_available>
    <id>42</id>
    <id_product>15</id_product>
    <id_product_attribute>0</id_product_attribute>
    <id_shop>1</id_shop>
    <id_shop_group>0</id_shop_group>
    <depends_on_stock>0</depends_on_stock>
    <out_of_stock>2</out_of_stock>
    <quantity>37</quantity>
  </stock_available>
</prestashop>

So what? For read-and-notify automations (new order → Slack, new customer → spreadsheet), you will likely never touch XML. For write-back automations (sync stock, change order status, create a customer), budget an afternoon to get the first payload right, after which you copy it for every similar Zap.

The connection options, ranked by how little you have to touch

The limits Zapier will not warn you about

No-code automation is the right tool for a huge range of jobs, and the wrong tool for a few. Knowing the edge before you hit it saves a painful migration later:

• Volume. Zapier bills per task. A store doing 30 orders a day across four automations is comfortable; one doing thousands of orders a day will watch the bill climb fast, at that point a direct integration or an ERP integration once you outgrow manual work is cheaper per transaction.
• Bidirectional, large-volume sync. Keeping stock, prices and orders in constant two-way agreement between PrestaShop and another big system is not what Zapier is for. See the patterns that actually hold up in ERP integration patterns that work.
• Accounting precision. You can push orders into accounting software through Zapier, but tax rules, credit slips and refunds get fiddly fast; a purpose-built bridge is usually saner, as we cover in connecting PrestaShop to your accounting software.
• Transactional email. Do not route order confirmations through a Zap, that belongs in PrestaShop's own mail system, configured properly. See email configuration in PrestaShop.

Three habits that keep no-code automations from biting you

• Scope the key, then forget it. The single biggest safety win is the permissions grid in Step 1. Grant the minimum, and a leaked key can do almost nothing.
• Test with a throwaway order first. Place a real test order and watch the whole Zap run end to end before you trust it. A silent automation that drops every third order is worse than no automation, because you stop checking. (If a test order's confirmation goes missing while you're at it, that's an email-delivery problem, not a Zapier one. Resend Order Confirmation lets you re-fire it from the order while you fix the cause.)
• Watch the task history for a week. Zapier logs every run; a write-back Zap that starts failing because PrestaShop returned an XML error will sit there quietly. Five minutes on Monday catches it.

Frequently asked questions

Is there really no PrestaShop app on Zapier?

At the time of writing, no PrestaShop-maintained app exists in Zapier's directory, because PrestaShop is self-hosted across many versions and modules, there's no single party to publish and certify one. You connect instead through PrestaShop's built-in Webservice API and Zapier's generic Webhooks by Zapier steps. Check the directory for any current third-party connectors before ruling them out, but the Webservice route is the dependable no-code path.

Is connecting PrestaShop to Zapier genuinely "no code"?

For reading and notifying, new order to Slack, new customer to a spreadsheet, yes, it's click-only: enable the Webservice, scope a key, and poll with a Webhooks GET. For writing back into your store (updating stock, changing order status), you'll meet a little XML, because the Webservice accepts changes as an XML body rather than form fields. There are no loops or logic, but it's more than dragging blocks, and you should know that going in.

How do I get PrestaShop orders into Zapier in real time?

Polling can't be truly instant, it checks on your schedule (e.g. every 15 minutes). For real-time you need the store to push: a webhooks module that fires an HTTP POST on order creation (hooking actionValidateOrder) to a Zapier Catch Hook URL. Core PrestaShop has no outbound webhook sender, so this needs a module, but a good one is configured entirely from the back office by pasting in the catch URL.

Why does my Webservice call return 404?

Almost always URL rewriting. The Webservice's /api endpoint depends on friendly URLs and the rewrite rules in PrestaShop's generated .htaccess. Confirm Shop Parameters → Traffic & SEO → Friendly URL is on and that your server actually rewrites (some Apache setups need mod_rewrite enabled). It's a server setting, not code.

Why does my Webservice GET return only ID numbers instead of order details?

You're missing display=full. Without it the Webservice returns a list of resource references (just IDs), not the fields you want to map. Add &display=full to the URL, or do a two-step fetch. List the IDs, then GET each order by its id.

Related reading

• Zapier and Make for PrestaShop. Choosing and operating the platform, with the Make-vs-Zapier comparison
• Email configuration in PrestaShop, why order confirmations belong in your mail system, not a Zap
• When your store outgrows manual work, your signal to graduate from glue to a real integration

Where this leaves you

The "without writing code" promise survives contact with PrestaShop. With one honest correction: there is no plug-in-and-go app, so you connect through the Webservice API and Zapier's generic webhook steps. For reading from your store and firing off notifications, that path is genuinely click-only. For writing back into your store, you will meet a little XML, and you should know that going in rather than discovering it mid-build. Start with one polling-based read automation, prove it on a test order, and add from there. When the volume or the two-way complexity grows past what a Zap can carry gracefully, that is your signal to graduate to a deeper integration. Not a sign you did the no-code part wrong.