E-commerce API and webhooks: syncing stock and orders with your ERP

Your online shop does not live on its own. Stock moves in the store, accounting waits for orders, and an ERP or a marketplace needs the right prices. To let these tools talk to each other without retyping anything, you need an API and webhooks. This guide explains what they are for, what the Eazyclick API can do, what it does not cover yet, and how to sync stock with an ERP.

At a glance

• An e-commerce API lets another piece of software read and update your shop's products, stock and orders.
• A webhook notifies that software as soon as something happens, so it does not have to keep polling the shop.
• The Eazyclick API (v1) covers products, stock and orders, with read or write keys.
• Two signed webhooks: order.placed (order placed) and stock.updated (stock changed).
• Published limits: 120 requests per minute for reads and 30 for writes, per key.

What is an e-commerce API?

An e-commerce API is a technical entry point into your online shop. It lets other software, such as an ERP or a marketplace, read the catalogue, stock and orders, and sometimes change them, without going through the admin screens. Data is exchanged as JSON, through HTTP requests secured with a key.

In practice, an API removes manual CSV exports and double entry. A developer or your integrator writes the link between the two systems once, and the data then flows by itself. This is what people usually call an integration.

API or webhook: what is the difference?

An API and a webhook work in opposite directions. With an API, your software asks the shop a question when it needs to, for example "what is the stock of this product?". With a webhook, the shop tells your software as soon as an event happens, such as a new order. A reliable sync uses both.

What the Eazyclick API can do

The Eazyclick open API, version 1, covers three parts of the shop: products with their variants, stock, and orders. Products can be read, created and updated. Stock can be read, set and given movements. Orders can be read, including by last-modified date. The API is part of the Full e-commerce module.

What version 1 does not cover, so there are no surprises:

• Customers, CRM and invoices are not exposed through the API.
• Stock per store: the API gives each variant's stock across all locations combined, without a per-store breakdown.
• In-store sales arrive through the order.placed webhook, but cannot be read with GET /orders.
• No ready-made connector is provided for any specific ERP: the API and webhooks let you build one.

Read and write keys

Access to the API goes through a key created in the shop settings. A read key looks up data, while a write key can also create products and set stock. The key is shown only once, can be revoked in one click and acts on behalf of the account owner, who can find every write in the activity log.

A few common-sense rules:

• One key per integration: revoking a provider's access then cuts off only that provider.
• The smallest scope that works: a price comparison tool only needs read access.
• Keep the key on a server, never in a web page or a code repository: it gives access to your customers' orders and addresses.

Signed webhooks: order.placed and stock.updated

Eazyclick sends two events to the address of your choice. order.placed fires for every order, online or at the till. stock.updated fires whenever a variant's stock changes, whether through a sale, an API write or a correction in the back office. Every delivery is signed, so your server can check that it really comes from Eazyclick.

• HMAC-SHA256 signature in the Eazyclick-Signature header, computed over the timestamp and the raw body with the endpoint secret. Reject timestamps older than 5 minutes.
• Stable event ID (Eazyclick-Event-Id): the same event can arrive twice, so deduplicate on this ID.
• Automatic retries if your server does not respond: after 1 minute, 5 minutes, 30 minutes, 2 hours and 6 hours, which makes 6 attempts over 8 hours 36 minutes.
• Delivery log, replay and a "Test" button in the back office, to check an integration without waiting for a real order.

Rate limits and pagination

The API applies published limits per key and per minute: 120 read requests and 30 write requests, counted separately. Beyond that, it returns 429 rate_limited with a Retry-After header telling you how many seconds to wait. Lists are paged at 100 items at most, and all amounts are expressed as whole cents.

These limits leave plenty of room for a normal sync. The documentation recommends webhooks for real time, an order catch-up every 5 to 15 minutes, a catalogue refresh every hour and a full stock reconciliation once a night. That pace fits easily within 120 reads per minute.

Use case: syncing stock with an ERP

To sync an ERP or a third-party POS with the shop, Eazyclick stays the source of truth for stock. The ERP first loads the catalogue, then receives every stock movement and every order by webhook, reports its own sales through the API, and checks everything each night. A single read and write key is enough for the whole scenario.

1. Initial load: GET /products, page by page, matching variants by SKU.
2. Real-time stock: subscribe to stock.updated and apply it on receipt.
3. Orders: order.placed in real time, plus GET /orders?updatedAfter=… every 5 to 15 minutes to catch a missed delivery.
4. Sales made outside Eazyclick: POST /variants/{variantId}/stock-movements for each sale.
5. Reconciliation: GET /stock every night, compared with the ERP database.

Still weighing up your options? Our comparison Odoo or Eazyclick sets out the differences. For a business with several stores, the multi-store retail page shows how stock, the point of sale and the online shop work together.

Documentation and OpenAPI specification

The API documentation is public, in English and French, and generated from the API code: every figure you read is the one the API applies. It includes a quick-start guide, authentication, pagination and errors, rate limits, sync frequency, webhooks with verification examples in Node, PHP and Python, and the full reference.

• API documentation in English
• API documentation in French
• OpenAPI specification, ready to import into Postman, Insomnia or a client generator.

Tools already connected to the modules are listed on the Integrations page.

Frequently asked questions

Is the API included in Eazyclick?

The open API is part of the Full e-commerce module: it comes with that module, with no separate add-on. Keys and webhooks are both set up in the shop settings. Without the Full e-commerce module, the API is not available, since it works on the shop's products, stock and orders and needs a shop to read from and write to.

Is there a ready-made connector for my ERP?

No. Eazyclick does not provide a ready-made connector for any specific ERP. The API and webhooks give you everything needed to write one: catalogue loading, real-time stock, orders and external sales. Your developer or your ERP integrator can rely on the documentation and the OpenAPI specification to build the connection.

Can you read customers or invoices through the API?

Not in version 1. The API covers products, variants, stock and orders. Customer records, CRM data and invoices are not exposed. An order does include the email address, the customer name and the addresses needed to process it, which is enough for most logistics and stock integrations.

What happens if my server is down?

Webhooks are retried automatically: six attempts in total, after 1 minute, 5 minutes, 30 minutes, 2 hours and 6 hours. After the last one, the delivery stays visible in the back-office log and can be replayed in one click. For online orders, a regular read with updatedAfter also catches up on a missed event.

Is stock available store by store?

Not yet through the API. Version 1 gives, for each variant, the shop's total stock across all stock locations: quantity on hand, reserved and available. The back office already manages stock per store. If your project needs that breakdown in the API, let us know: such an addition can be made without breaking version 1.