PrestaShop APIs and integrations: Webservice, ERP, Zapier and Make

What we would do

We would start with the manual job or failure you can measure, then check whether your existing integration can already handle it. For an ongoing exchange, start with a scheduled incremental job when the business can tolerate the delay. Choose a maintained connector if it fits the complete workflow; commission a worker or module when the missing business rules justify owning custom code.

The route depends on your installed PrestaShop and PHP versions, modules, other integrations, theme and checkout customisations, data quality, combinations and multistore setup. Include the markets, currencies and tax cases you serve, the receiving system's capabilities and the team available to operate it. Rehearse a change on a staging copy with representative data and the same relevant configuration, isolated from live customer mail, warehouse dispatch and production writes to other systems. Plan the switch and reversal before enabling the live writer.

If you need a connector built around these rules, the PrestaShop Custom Module Development Service starts from a written specification and acceptance criteria for the agreed connections.

Choose the smallest route that meets the requirement

Choose the API and define the integration contract

The legacy Webservice is a core feature. It provides resource-oriented HTTP access, XML requests and XML or JSON responses in PrestaShop 1.7.8 and 9.1. PrestaShop 9 also has an Admin API with OAuth2 and JSON. These APIs have different authentication, routes and coverage.

Before choosing, list the exact operations you need: product creation, combination mapping, stock updates, order export, refunds, tracking or accounting documents. Check the installed shop's resource list and generated documentation. Do not assume that either API covers every operation in every release. For each operation, record its source, destination, shop context, required fields, expected business effects and acceptance response. A connector that reads an order may still lack the credit-slip or tracking operation your process needs.

Prefer an API or supported application service for ongoing writes. Direct SQL bypasses application validation, hooks and other processing. A specialist migration must explicitly handle associations, indexing, stock, media and cache invalidation; clearing cache alone is insufficient. There is no universal catalogue-size threshold that makes direct SQL the correct choice.

This guide starts with the Webservice mechanics, then covers ERP design and automation platforms. See the official Webservice documentation for the installed version's details.

Enable access and verify routing

1. Open Advanced Parameters, Webservice. Enable the Webservice.
2. Create a separate active key for each integration.
3. Grant only the required resources and methods in the correct shop context.
4. Store the key in a secret store or a protected credential file outside source control.
5. Test access from the actual integration runner over HTTPS.

For HTTP Basic authentication, the key is the username and the password is empty. The dispatcher also accepts ws_key in a query string, but avoid that transport because URLs can enter logs, histories and analytics.

The examples use a private curl configuration file named by WS_CURL_CONFIG. In Bash, enter the shop's actual HTTPS base URL, including any installation subdirectory, and the integration key. The temporary credential file is removed when this shell exits. Keep the same shell open for the later curl examples.

umask 077
read -r -p 'Shop HTTPS base URL: ' SHOP_URL
read -r -s -p 'Webservice key: ' WS_KEY
printf '\n'
WS_CURL_CONFIG="$(mktemp)"
trap 'rm -f "$WS_CURL_CONFIG"' EXIT
printf 'user = "%s:"\n' "$WS_KEY" > "$WS_CURL_CONFIG"
unset WS_KEY
curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  "$SHOP_URL/api/?output_format=JSON"

The API route and the dispatcher

/api is normally a virtual route. Apache's generated rules map it to webservice/dispatcher.php with a url parameter. That API rule is generated independently of the storefront Friendly URL setting.

For Nginx, preserve the resource path and original arguments. The standard rewrite shape in the official configuration is:

rewrite ^/api/?(.*)$ /webservice/dispatcher.php?url=$1 last;

For a shop installed under /shop/, adapt both sides:

rewrite ^/shop/api/?(.*)$ /shop/webservice/dispatcher.php?url=$1 last;

These rules belong in a correctly configured server with its existing PHP handling. For example, /shop/api/products?limit=5 must reach the dispatcher with url=products and limit=5. Nginx appends the original arguments with this rewrite form. Test the effective server configuration and both routes after reloading.

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  "$SHOP_URL/webservice/dispatcher.php?url=products&limit=1"

If direct dispatcher access works but the API route fails, inspect rewriting, the base path and proxy routing. Apply IP restrictions and rate limits to both the friendly route and the actual dispatcher. An .htaccess file in a nonexistent /api/ directory does not secure the PHP endpoint. Check restrictions after any internal rewrite.

Discover resources, schemas and response formats

The API root shows resources available to the authenticated key. Common groups include products, categories, combinations, attributes, customers, addresses, orders, order details, order histories, carriers and stock availability. Images have their own management routes.

Do not copy a universal resource list from another release. For example, supply_orders is in the PrestaShop 1.7.8 resource list and absent from the 9.1 list.

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error --get \
  --data-urlencode 'display=[id,reference,active]' \
  --data-urlencode 'limit=5' --data-urlencode 'output_format=JSON' \
  "$SHOP_URL/api/products"

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error --get \
  --data-urlencode 'display=[id,id_product,id_product_attribute,quantity]' \
  --data-urlencode 'limit=5' --data-urlencode 'output_format=JSON' \
  "$SHOP_URL/api/stock_availables"

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  "$SHOP_URL/api/products?schema=synopsis"

Without a display selection, resource collections commonly return IDs and links. Use selected fields for lists, display=full when you need the whole writable context, or fetch individual resources. Inspect the actual response before mapping it into another system. In an automation editor, inspect whether the response is a collection and how it becomes individual destination actions. Mapping only the first returned object can pass a single-order test while losing the rest of the page.

schema=blank gives a resource template. schema=synopsis adds required flags, validation formats, lengths and read-only information. It is not a declaration of every filter the API accepts.

Square brackets are part of Webservice query syntax. Quoting a URL protects it from the shell but does not disable curl's own URL globbing. Use --globoff, encode the brackets, or construct queries with --get --data-urlencode. See the curl manual.

Filter, sort and paginate without losing changes

For date_add or date_upd filters, include date=1. PrestaShop 1.7.8 and 9.1 remove those fields from the allowed filter list without it, so the request can return HTTP 400.

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error --get \
  --data-urlencode 'date=1' \
  --data-urlencode 'filter[date_upd]=[2026-10-01 00:00:00,2026-10-02 00:00:00]' \
  --data-urlencode 'sort=[date_upd_ASC,id_ASC]' \
  --data-urlencode 'display=[id,reference,current_state,date_upd]' \
  --data-urlencode 'limit=0,100' --data-urlencode 'output_format=JSON' \
  "$SHOP_URL/api/orders"

A complete new-order poll

1. Persist the last successfully processed order ID, with a separate value per shop or source.
2. Fetch orders with an ID above that watermark in ascending order. A bounded range such as filter[id]=[next_id,upper_id] can define a run.
3. Page until all matching orders have been processed. A latest-five sample is not a complete poll.
4. Make the destination action idempotent and record success.
5. Advance the watermark only past successfully completed work, or persist failed items durably before moving on.

For updates to existing orders, use a bounded modification-time window and a stable tie-breaker such as ID. Retain overlap and deduplicate records because timestamps can be shared and concurrent changes can move rows between pages. Save the window only after completing it. Related records need their own change handling: updating an order-carrier tracking number does not necessarily update the parent order timestamp. Reconcile related data rather than relying on an orders-only poll.

Choose intervals from measured latency, stock velocity and API load. An hourly catalogue job and a frequent stock worker have different requirements. There is no single best interval for every shop.

Create and update complete writable resources

Use a blank schema for creation, fill the required fields and validate IDs in the target shop. Do not assume category 2, language 1 or tax group 1 has the intended meaning. For a product, check its name and friendly URL per language, default category, category associations, price, tax configuration, active flag and publication state.

For a PUT, fetch the resource, compare it with its synopsis, remove non-writable fields and preserve the required writable fields and associations. Modify the intended values and submit XML with the correct Content-Type. A product GET can contain a non-writable field such as manufacturer_name; putting the response back unchanged can fail.

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  "$SHOP_URL/api/products/42" -o product.xml

# Edit and validate product.xml, removing read-only fields first.
curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  --request PUT --header 'Content-Type: application/xml' \
  --data-binary @product.xml "$SHOP_URL/api/products/42"

Use only disposable staging records for write examples. In the PrestaShop 9.1 Webservice, PATCH supports partial updates. Check the installed version, key permissions and resource before choosing it; PrestaShop 1.7.8 does not support PATCH.

For a PrestaShop 9.1 stock record whose ID you have checked, a partial payload includes its resource ID:

<prestashop>
  <stock_available>
    <id>89</id>
    <quantity>100</quantity>
  </stock_available>
</prestashop>

Submit this with PATCH to /api/stock_availables/89, not as an abbreviated PUT. If PATCH is unavailable, GET the stock record and preserve all required writable values for PUT. In either case verify the product, combination and shop before writing, then re-read the quantity.

Check transport errors, HTTP status and the response body for every item in a batch. Retry transient read failures with backoff, a maximum delay and an attempt or elapsed-time limit, respecting any rate-limit response. Keep exhausted items recoverable and alert the operator. After an uncertain write, reconcile the actual outcome before retrying. A blind repeat of a create request or stock delta can duplicate its effect. Keep a durable external-to-local mapping and record unresolved items for recovery.

Use an XML serializer to escape text. CDATA can contain markup, but must handle its own terminator correctly. Send UTF-8 and a prestashop root element.

Deletion

DELETE is destructive and has no general recycle bin. Prefer disabling an item when that meets the business need. For disposable records only, bulk deletion uses comma-separated IDs such as ?id=[42,43,44], with curl globbing disabled. Pipes belong to filter syntax, not this deletion list.

Handle images, combinations and stock context

Images

Image upload uses multipart data rather than product XML. Inspect image types and processing limits in the target shop.

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  --form 'image=@photo.jpg;type=image/jpeg' \
  "$SHOP_URL/api/images/products/42"

curl --config "$WS_CURL_CONFIG" --globoff --fail --silent --show-error \
  "$SHOP_URL/api/images/products/42"

A specific image/type route can look like /api/images/products/42/15/large_default, when that type exists. Image deletion uses the image resource route and DELETE. Test dimensions, format, upload limits, memory and thumbnail generation with representative files. There is no universal 2048-pixel or 5-MB failure boundary.

Combinations

1. Create or map the attribute group, such as Size, through product_options.
2. Create or map its values, such as M, through product_option_values.
3. Create the combination for its parent product and associate the correct value IDs.
4. Store a stable external mapping and a unique sellable-item reference.

A combination's price is an impact on the base product price, not its final selling price. If the source supplies a final base-plus-impact price, calculate the impact in the correct currency and tax basis. Set other required values, such as minimal quantity, from the schema and business requirements.

Stock availability

Locate stock_availables using product ID, combination ID and the correct shop or shared-shop context. Products without combinations use attribute ID zero. For products with combinations, update the intended combination records; do not overwrite the product-level aggregate as if it represented a particular size or colour.

Preserve out-of-stock and stock-dependency settings. Decide whether values are absolute snapshots or deltas, who owns reservations and how orders in transit to the ERP are accounted for. A delayed authoritative snapshot can still overwrite a newer local deduction if that contract is wrong.

Export orders and control state, tracking and email effects

Read an order from /api/orders/1234 and its related rows from order_details filtered by id_order. Check addresses, currencies, tax totals, discounts, payment information, invoices and credit slips required by the receiving system.

Discover order_states from the actual shop. Do not hard-code the common default numeric IDs. State flags can affect stock, invoice or delivery processing, as well as notifications.

For a deliberate workflow transition, POST an order_history record. Request mail explicitly with sendemail=1 if intended; the state's email configuration and a valid template also matter.

<prestashop>
  <order_history>
    <id_order>1234</id_order>
    <id_order_state>4</id_order_state>
  </order_history>
</prestashop>

This is a staging example with illustrative IDs. Its email-requesting endpoint is /api/order_histories?sendemail=1. Without that flag, OrderHistory::addWs() changes state and stores history without requesting the status email itself. Other modules listening to state changes may have separate effects. Do not change states merely to resend a message.

Tracking numbers are represented through order_carriers. Fetch the correct carrier record, retain writable fields and update the tracking number. Verify the resulting mail and carrier-link behaviour in your version; do not assume every API write has the same side effects as every back-office command.

Order creation

The Webservice order-creation method calls the named payment module's validateOrder(). It does not simply bypass order validation, stock processing and hooks. You need a valid cart, customer context, compatible payment module and Webservice payment state configuration, including PS_OS_WS_PAYMENT.

Validate amounts, tax, shipping, currency, payment semantics and duplicate protection in staging. An imported marketplace payment is not a new card charge. Check all emails and stock effects generated by the selected path. Use a supported connector or a custom application operation when you need explicit control over a more complex transaction.

Use the PHP client and expose module data deliberately

The official PHP Webservice client provides XML helpers around HTTP requests. Select a library version compatible with your runtime, keep debugging disabled in production and do not print credentials or complete customer responses into logs.

composer require prestashop/prestashop-webservice-lib

For an incremental query, the client's options must include the date flag too. This example assumes the client and credentials are already initialised:

$options = [
    'resource' => 'orders',
    'date' => 1,
    'filter[date_upd]' => '[2026-10-01 00:00:00,2026-10-02 00:00:00]',
    'display' => '[id,reference,current_state,date_upd]',
    'sort' => '[date_upd_ASC,id_ASC]',
    'limit' => '0,100',
];
$xml = $ws->get($options);

This is one page of a bounded query, not a complete synchronisation loop. Apply the watermark, pagination and failure handling described earlier. For stock updates, reject zero or ambiguous lookup results before editing any returned record.

A module can expose its own ObjectModel through addWebserviceResources. For example, an articles resource can name the module's Article class and forbid DELETE. Define its data shape with $webserviceParameters, limit exposed fields and verify permissions and synopsis output. The class and its validation must actually exist; a resource declaration alone does not implement an endpoint's business model.

Use the custom resource documentation and the official PHP client source when implementing this layer.

Evaluate the PrestaShop 9 Admin API separately

The Admin API uses OAuth2 client credentials, scoped authorisation and JSON through a Symfony/API Platform implementation. Consult the installed /admin-api/docs and the Admin API documentation for available operations and scopes.

The token route is /admin-api/access_token. Supply the configured client credentials and required scopes, then use the returned access token as a Bearer token. Read the response's expiry rather than hard-coding a one-hour lifetime. With client credentials, request another token when needed; do not assume a refresh-token flow.

Create a separate client for the integration and grant its documented scopes. Do not reuse a legacy Webservice key or assume that a similarly named resource uses the same route or payload. Test the entire required workflow before selecting the Admin API or combining both APIs.

Diagnose responses and protect both API routes

Compare the API route with the direct dispatcher using the same key and request. The examples use curl's --fail, which suppresses HTTP error bodies: for diagnosis use --fail-with-body where your curl supports it, inspect the status and response body, and redact sensitive details before sharing them. Check Authorization header forwarding, shop context, method permissions, exact resource names and encoded query parameters.

Use separate credentials, least privilege, HTTPS and a documented rotation and revocation process. Restrict known server callers where feasible. Cover the dispatcher as well as the rewritten URL with appropriate rate and access controls.

Log operation IDs, source, direction, timings, status, retries and a useful redacted error. Use payload hashes or minimised diagnostic data where possible. Never log keys, Authorization headers or unnecessary personal information. Define access and retention. API auditing is a useful security control, not a universal legal prescription to record every resource read.

Design ERP ownership, retries and reconciliation

Start with one owner per field. A possible arrangement is ERP-owned product, price and inventory data, with PrestaShop-originated orders and customer changes sent outward. Another business may use a PIM or WMS for part of that role. Document it explicitly rather than assuming the ERP always wins.

Store stable external IDs with local IDs. Names are not identifiers, and references can be edited or duplicated unless you enforce their stability. Map products and combinations separately.

Use an idempotency key that identifies the source, entity, operation and stable event or version. A retry must not duplicate an invoice or stock deduction, while a later valid update must still be processed. Mark success only after completion and retain recoverable failures.

PrestaShop's standard hooks are local events, not a general durable outbound webhook service. Use actionValidateOrder for the payment-module order-creation event. Use actionOrderStatusPostUpdate for explicit status transitions with deduplication, not as an interchangeable new-order trigger.

For actionProductUpdate, some dispatches contain only id_product. Resolve and validate a Product when no object is supplied, and include the correct shop and language context. Stock events need combination and shop identifiers. Queue delivery rather than blocking a back-office save or checkout on a remote HTTP request.

Sign or otherwise authenticate outbound events, use timeouts and retries, and design for duplicate or out-of-order delivery. Reconcile stock and orders regularly. Report drift and apply corrections only under a documented ownership and reservation policy.

Worked example: an order reaches the warehouse, but the reply is lost

Assume your warehouse system owns sellable stock and shipment details, while PrestaShop creates the customer order. The warehouse accepts orders for fulfilment only at the payment or approval stage you have agreed. A new order and a fulfilment-ready order are different events; record the eligibility rule rather than forwarding every created order to picking.

1. The worker reads an eligible order, resolves its combination mappings and submits the warehouse request with a stable source-order key.
2. The warehouse accepts it, but the network times out before the worker receives the acceptance reference. Keep the item unresolved; a timeout does not prove the warehouse rejected it.
3. Look up the source-order key at the warehouse. If it exists, save its acceptance reference. If the receiver supports repeat-safe submission with that key, use that documented mechanism. Otherwise require reconciliation before submitting again.
4. Once acceptance is recorded, a replay must not create another pick. A later cancellation or amendment follows its own operation and acknowledgement, rather than being suppressed as a duplicate order.
5. Compare eligible source orders with accepted warehouse requests and surface unmatched records. When tracking arrives, match it independently of the original order poll.

Now consider a stock snapshot prepared before this order reached the warehouse. If it still includes the unit deducted by the shop, applying it unchanged can make that unit sellable again. The agreement must identify outstanding reservations and snapshot ordering. Test this overlap with a delayed export before allowing automatic stock corrections.

There is no universal core cron URL. Name the actual command or supported module endpoint, its runner and its failure alert. Cron Manager provides task management for supported jobs, as its help page explains; scheduling a task does not create the ERP connector, mapping or reconciliation logic.

Decide whether an ERP or a smaller export is justified

Look for repeated order re-entry, unreliable stock, slow month-end reconciliation, multiple sales channels and unclear fulfilment ownership. These are symptoms to measure, not an order-volume or team-size threshold that proves you need an ERP.

1. Record time spent re-keying orders, invoices, addresses, stock and tracking during a representative week.
2. Multiply those hours by the loaded cost of the people doing the work.
3. Record actual correction costs: returns, duplicate invoices, refunds, oversells and reconciliation work.
4. Test whether the process can handle a plausible increase, such as 50% more orders. This is a planning scenario, not an industry threshold.
5. Compare the recurring burden with implementation, licensing, hosting, maintenance, support and failure-recovery costs.

Work through an order-to-accounts export before buying an ERP

Suppose staff copy order lines into accounts and separately copy delivery details into a warehouse tool. Trial the accounts export with a file the accountant can actually import. If it removes accounting entry but leaves warehouse entry and refund checks, count only the work it removes. Do not credit the export with savings that require a later integration.

Convert monthly error and subscription costs to the same period as the weekly time log before comparing them. If recurring savings are positive but cannot recover the setup cost within your planning period, narrow the scope or keep the repeatable manual process. If repeated stock mistakes dominate the cost, an accounts-only export leaves the main problem untouched. For the document mapping, use the accounting and invoices guide.

A repeatable manual file export may solve one bottleneck. A scheduled exchange requires an actual supported runner. There is no fixed 100-orders-per-day boundary between files, automation and an ERP.

Orders CSV List Exporter provides authenticated back-office exports and scheduled email or server delivery; confirm the installed release's scheduling options, required runner and recipients before relying on unattended exports.

For invoice-specific export capabilities, see the Invoice CSV List Exporter help page.

Prioritise the measured problem. Orders to accounting, inventory updates, tracking and customer records have different mappings and risks. Assign an owner to monitor the integration after launch. One authority for stock improves clarity but does not alone eliminate overselling.

Compare Zapier, Make and a direct integration

Use an automation platform when its available apps and error handling suit the workflow. Verify the current app directory, supported operations and PrestaShop version rather than assuming an official connector exists or cannot exist because the shop is self-hosted. Compare the destination app as well: Make may expose the shop operation you need, while Zapier may better support the other tool, or the reverse. In Zapier a workflow is a Zap; in Make it is a scenario. Test the complete chain with your sample data rather than choosing by app count.

Make provides a PrestaShop app. Do not treat a Watch module as an instant webhook without checking its trigger type. Generic HTTP access is an alternative when an app does not expose the needed resource.

Zapier meters tasks under its plan rules. Make now uses credits: ordinary non-AI operations commonly consume one credit, while some features use other accounting. Compare a representative run including searches, loops, empty checks, retries and downstream actions. Do not use old operation-based price tables as current prices.

For an illustrative workload, 200 orders per day times five actions times 30 days is 30,000 action executions. That is not automatically 30,000 billable units on either service; apply the current billing rules. A native module still has hosting, maintenance and possible external-service costs.

Make publishes zone-specific egress IPs without the assumed paid-plan restriction. Zapier documents static IP support on Professional and higher for specified apps, including Webhooks. Use the current list for the actual app and zone.

Keep accounting precision, stock reservations and complex combinations in a workflow that implements them correctly. The fact that a tool is local or uses a hook does not guarantee instant delivery, lower cost or availability during another provider's outage.

Mailchimp Integration syncs opted-in audience membership and retries failed contact syncs, rather than providing catalogue, segment or order synchronisation, as its module help page explains. Check subscription and unsubscribe handling before connecting another audience writer; the existence of a customer account is not itself an instruction to subscribe it.

Build and operate a complete first automation

A simple first workflow is an order notification or a reporting row. For a spreadsheet trial, set Basic authentication in the platform's credential fields with the Webservice key as the username and an empty password, fetch the required order fields, process every returned order and map the shop, order ID, reference and current status into the spreadsheet's create-row action. Apply the recovery checklist below: a polling trigger marking an item as seen does not prove that its destination action completed. Keep it read-only while you verify credentials, data mapping and failure handling. Avoid exposing full customer details in a team message when an order reference and secure back-office link will do.

1. Choose a supported polling trigger or schedule. Schedule by Zapier documents hourly and longer triggers; it is not a generic every-15-minute trigger.
2. For a poll, check Webhooks by Zapier Retrieve Poll and your account's supported interval, or implement a bounded scheduled query.
3. Read all orders above a stored watermark, in ascending order, and paginate. Map either selected fields or explicitly fetched full resources.
4. Process each order with a stable deduplication key. Persist the destination result and advance state only when the action is safely recorded.
5. Test more orders than fit in one page, a duplicate event, a timeout and a failed destination action.
6. Enable failure alerts and record the workflow's owner, credential, schedule, mappings and recovery procedure.

For push delivery, a module must send the appropriate event to the receiver's Catch Hook or equivalent URL. Installing a receiver does not make PrestaShop emit outbound events. Keep status-change and order-creation messages distinct.

For write-back workflows, validate the XML and use the correct resource, combination and shop. A form-based automation editor does not remove the need to understand PUT, PATCH, tax or order effects. When moving beyond read-only steps, keep the write credential separate and grant it only to the worker that needs it. If the editor cannot preserve the writable resource or safely recover an uncertain write, use a maintained bridge or an application operation for that step.

Check execution history regularly and after shop or module updates. Test customer mail through the intended shop or provider transport rather than adding a second accidental order-confirmation path. Go live one workflow at a time, with a clear way to stop and replay work safely. Keep a successful sample response and expected destination result for regression checks after updates. A changed field shape or an empty mapping may leave the HTTP request successful while producing an incomplete destination record. For mail transport checks, see the email configuration guide.

What to ask your developer or agency

Give the implementer sample records from the shop and receiving system, a description of the current manual process and the outcome staff must see. Include awkward cases from your own data: combinations, discounts, different tax treatments, refunds, edited addresses and split fulfilment where used. Ask for a written answer to these questions before accepting the build scope.

• What already fits? Which installed connector, native export or supported API operation can be reused, and which exact requirement needs development?
• What is the mapping? Which source fields become which destination fields, with what currency, tax basis, rounding, language and shop context? Who approves a rejected or ambiguous match?
• When is work eligible? Which payment or order event authorises export, what counts as acceptance, and how are later amendments, returns and cancellations represented?
• What is the delivery promise? Specify an acceptable end-to-end delay, expected workload, outage backlog and recovery target. Measure destination completion, not just the poll schedule.
• How does support work? Who owns credentials, code, mappings and hosting, who responds to failures, and who retests after a shop, module or receiving API update? Include access to source, instructions and recovery records in the handover.

Agree acceptance evidence

Rehearse the change and plan the live switch

1. Prepare the isolated copy. Replace copied production keys and receiver URLs, disable live scheduled senders and route mail to a test destination. Check every outbound path, including existing modules, before creating rehearsal orders.
2. Establish the baseline. Record versions, settings, mappings, current integration progress and representative stock and order results. Prove that the relevant backups can be restored and save the configuration needed to return to the previous route.
3. Run the acceptance cases. Use disposable staging records and test accounts at the receiving end. Include your actual checkout, payment modules and staff actions so that the events and side effects come from the path you will use live.
4. Set the handover boundary. If replacing an integration, agree the last completed item or window owned by the old process and the first owned by the new one. Transfer outstanding failures and mappings, and prevent both workers from writing the same fields during the switch.
5. Switch in an agreed window. Save progress, pause the outgoing writer, apply the reviewed configuration and enable the new runner. Verify destination acceptance and queue age as well as successful HTTP responses. Name who can stop the change if acceptance fails.
6. Keep a recovery ledger. Retain the requests accepted on either side of the boundary. Reversal may restore code or settings, but accepted invoices, picks, emails and stock changes need their own reconciliation. Resume the previous writer only from a checked boundary that accounts for work already completed.

After the switch, compare eligible source work, accepted destination records and unresolved failures for the same period. Review the oldest unprocessed item and the last completed reconciliation, not only the last scheduled start. Agree who handles an alert and when to escalate it; a green scheduler alone does not show that the business exchange has finished.

Questions owners ask

Do I need to replace my existing ERP?

First test whether it can receive and return the data in your contract, through a supported connector, files or an API. A missing connection can justify a small bridge; changing the back-office system needs a separate business case.

Can I do this without a developer?

An occasional export or read-only notification may be manageable with your existing tools. Before trusting an editor with writes, check whether you can explain and recover its failures. Use the route selector for the starting choice and the acceptance table to judge the result.

Will a theme change fix an integration?

Trace the missing field or event first. An API mapping fault needs a data fix. A customised checkout that changes order creation needs testing with the integration, so keep the relevant theme and checkout behaviour in the rehearsal copy.

Can I test by sending a real order to the warehouse?

Agree a test account or a controlled procedure with the receiver first. A copied order can still cause a real pick, invoice or customer message if the staging sender uses live credentials.

Does switching the module off undo what it sent?

No. Use the recovery ledger in the switch checklist to identify accepted work and arrange any required cancellation or correction with its owning system before resuming another writer.

What should I receive at handover?

The agreed mappings, tested cases, runner and credential instructions, alert ownership and a demonstrated stop-and-recovery procedure. Confirm responsibility for future compatibility work and its cost separately from fixing defects in the delivered scope.