Incoming API: the Webhooks/Pushers tab

Set the token your ERP or POS sends, switch on what it may change, and find the built-in API reference.

Where to find itShopSettingsWebhooks/Pushers

Before you start

Calls are accepted only when your plan includes "Webhooks & developer API".

Plan

Growth

Needs

Included with the plan

Who can use this

Shop owner

The incoming API lets your own systems write to the shop: products, stock, prices, customers and price lists. It can also read orders and adjust order lines. This tab holds its token and switches.

The tab opens with the heading Connect your ERP, POS or other systems.

The Webhooks/Pushers tab with the token row, the three switches, the base URL and the endpoint list numbered; the token value is hidden

Connection

Field	What it does
1. Webhook token	The secret your systems send with every call. The box is read-only. Select Generate Token to fill it with a new random token
2. Item webhook	Allows creating and updating products with `item-create`
3. User webhook	Allows creating and updating customers with `user-create`
4. Vendor type webhook	Allows vendor types, their prices and their customers. It must be on for any vendor-type call

All four are yours to change. Nothing on this tab needs support. The switches are off on a new shop.

Stock updates and the order endpoints have no switch. They work as soon as a token is saved.

If your plan does not include the feature, Item webhook and User webhook are locked with a Managed by platform badge. See Plan and access.

API reference on the tab

Under API reference the tab shows:

1. Base URL with a Copy button. It is your panel address followed by /api/webhook.
1. Jump to: a link to each endpoint.
One panel per endpoint with its fields, a JSON body example and a cURL example. Endpoints behind a switch carry a Needs: … label.

The examples use made-up data and the placeholder YOUR_WEBHOOK_TOKEN.

How every call works

Rule	Detail
Method	POST, with `Content-Type: application/json`
Token	Header `Authorization: Bearer <your token>`. A `password` field in the JSON body is also accepted
Wrong or missing token	HTTP 401, "Authentication failed"
Limit	500 requests a minute. Beyond that the answer is HTTP 429
Invalid fields	HTTP 422, "Validation failed", with one message per field under `data`

curl -X POST 'https://<your panel address>/api/webhook/stock-update' \
  -H 'Authorization: Bearer <your token>' \
  -H 'Content-Type: application/json' -H 'Accept: application/json' \
  -d '{"products_info":[{"ID":"SKU-10045","qty":100}]}'

Prefer the header. On user-create the body field password is also the customer's password, so the two meanings collide.

Endpoints

Group	Endpoints	Page
Catalogue	`/item-create`, `/stock-update`, `/stock-update-by-order`	Products and stock
Customers	`/user-create`	Customers
Vendor types	seven `/vendor-type-…` endpoints	Vendor types
Orders	`/order/details`, `/order/updates`	Orders

Connection

Field

What it does

1. Webhook token

The secret your systems send with every call. The box is read-only. Select Generate Token to fill it with a new random token

2. Item webhook

Allows creating and updating products with item-create

3. User webhook

Allows creating and updating customers with user-create

4. Vendor type webhook

Allows vendor types, their prices and their customers. It must be on for any vendor-type call

All four are yours to change. Nothing on this tab needs support. The switches are off on a new shop.

Stock updates and the order endpoints have no switch. They work as soon as a token is saved.

If your plan does not include the feature, Item webhook and User webhook are locked with a Managed by platform badge. See Plan and access.

API reference on the tab

Under API reference the tab shows:

Base URL with a Copy button. It is your panel address followed by /api/webhook.

Jump to: a link to each endpoint.

One panel per endpoint with its fields, a JSON body example and a cURL example. Endpoints behind a switch carry a Needs: … label.

The examples use made-up data and the placeholder YOUR_WEBHOOK_TOKEN.

How every call works

Rule

Detail

Method

POST, with Content-Type: application/json

Token

Header Authorization: Bearer <your token>. A password field in the JSON body is also accepted

Wrong or missing token

HTTP 401, "Authentication failed"

Limit

500 requests a minute. Beyond that the answer is HTTP 429

Invalid fields

HTTP 422, "Validation failed", with one message per field under data

curl -X POST 'https://<your panel address>/api/webhook/stock-update' \ -H 'Authorization: Bearer <your token>' \ -H 'Content-Type: application/json' -H 'Accept: application/json' \ -d '{"products_info":[{"ID":"SKU-10045","qty":100}]}'

Prefer the header. On user-create the body field password is also the customer's password, so the two meanings collide.

Group

Endpoints

Page

Catalogue

/item-create, /stock-update, /stock-update-by-order

Products and stock

Customers

/user-create

Customers

Vendor types

seven /vendor-type-… endpoints

Vendor types

Orders

/order/details, /order/updates

Orders