How does the Comax API authenticate?

With a LoginID and LoginPassword pair sent with the call, against web services at ws.comax.co.il. Because this is a long-lived credential rather than an expiring token, there is no expiry to signal a problem - it keeps working until someone changes it, including after a leak. Store it as a server-side secret and have a rotation plan.

Is the Comax API a REST API?

Not in the modern sense. It is a web-service style interface built around named operations - such as retrieving customer details by search - rather than resources addressed with HTTP verbs. Discover what exists by reading the operations list from your own installation rather than searching for examples, since code written against a different version fails confusingly.

Why does a retail store oversell despite frequent stock syncing?

Because the physical till sells the same stock and does not wait for your sync. On a last unit in high demand, no sync frequency closes the gap between a sale at the counter and the website knowing about it. The fix is not faster syncing but a stock buffer - showing less online than exists - or explicit allocation, and that is a business decision.

What should be checked before starting a Comax store integration?

Duplicate barcodes in the catalogue, which is the join key and is rarely clean in retail - the same code often appears on two variants, or was replaced historically. Also decide in writing which stock figure and which branches the store sells from, and what happens on a last unit. Each of these changes the integration, and discovering them mid-build costs weeks.

Should the integration create customer cards in Comax automatically?

Only on a confident match. When the search returns nothing certain, book the order under a walk-in customer and flag it for human review rather than creating a new card. Duplicate customer cards pass every test, accumulate quietly, and surface months later as reports that do not reconcile - at which point someone has to merge history by hand.

Comax API Integration Guide - Yehonatan Saadia

Comax exposes web services at ws.comax.co.il authenticated with a login pair. What that shape means for your architecture, the four flows a retail integration decomposes into, and why the POS is the constraint nobody plans for.

Comax is an Israeli retail ERP, and most projects around it are the same project: connect it to an online store so catalogue, stock and orders flow between the two. The interface exposes web services at ws.comax.co.il, authenticated with a LoginID and LoginPassword pair.

This guide covers what that shape implies and the retail decisions - not a field specification. Take the exact request structure from your installation's own operations list, because web services vary between versions and installations.

What that shape implies

Named operations, not resources

This is a web-service style interface: named operations - retrieving customer details by search, for instance - rather than resources with HTTP verbs. There is no GET /customers/123 and no DELETE.

If you arrive with REST expectations, that is the first point of confusion. The right way to discover what exists is to read the operations list from the installation itself, not to search for examples - with interfaces like this, code written for a different version fails in confusing ways.

Long-lived credentials

A login pair sent on every call is not an expiring token. Two consequences:

There is no expiry to tell you something is wrong. The credential keeps working until someone changes it manually, including if it has leaked.
You need a rotation plan. An employee leaving, a supplier contract ending - those are moments when it must change, and if the credential is hard-coded that becomes a project.

Environment variables or a secrets manager only. Not source control, not logs, and not anything running in a browser.

The four flows

A retail integration decomposes into four one-way flows, and only one is urgent:

Flow	Direction	Freshness
Catalogue and prices	Comax → store	Scheduled
Stock	Comax → store	Scheduled, frequent
Orders	Store → Comax	Near real-time
Fulfilment and status	Comax → store	Scheduled

The full pattern is in connecting an Israeli ERP to anything. What is specific to retail follows.

What makes retail different: the till

This is the central difference between a retail integration and an ordinary ERP integration, and it sinks projects that did not plan around it.

In a retail business the same stock is sold in two places simultaneously - on the website and at the physical till. The till does not wait for your sync.

Three questions determine whether the sync works:

Which stock does the store sell? Physical or available-to-sell? Online selling wants available - otherwise you sell units already allocated.
From which branches? Blindly summing all branches commits you to stock sitting somewhere else.
What happens on the last unit? If one unit remains and it sells at the till, how long before the website knows? That gap is where you sell stock you do not have.

The practical conclusion: no sync frequency solves a last unit in high demand. If the business sells unique items or end-of-line stock, the answer is not more frequent syncing but a buffer - showing less on the site than exists - or explicit allocation. That is a business decision that belongs in the requirements.

The join key: barcode

You need a stable identifier linking a Comax item to a store item. Barcode or SKU is the natural choice - but only if genuinely unique.

In retail this is almost never clean: the same barcode on two colour variants, an internal barcode replaced three years ago, items with no barcode at all.

One query counting duplicate barcodes before development starts saves a week. If duplicates exist, that is cleanup work which has to happen before the integration rather than instead of it.

What must be in place

A documented two-way link. The store's order id on the Comax document, and the document number on the order. Without it every enquiry becomes a manual comparison.
Idempotency. The same order arriving twice must produce one document.
A daily reconciliation job. Compare orders and stock across both sides for the last 24 hours. In retail a stock discrepancy is a customer who ordered something that does not exist, so this is not a luxury.
An error queue a human sees. An order that failed to import is a lost order if it is stuck in a log.

Customer matching

One of the operations the interface exposes is retrieving customer details by search - and that is exactly where care is required.

The rule: if there is no confident match, do not create a new customer card automatically. Book the order under a walk-in customer and flag it for review. Duplicate customer cards fail no test - they accumulate and surface six months later in a report that does not reconcile.

Checklist before pricing

Obtain the installation's operations list - do not rely on web examples.
Check for duplicate barcodes in the catalogue.
Decide which stock and which branches the store sells from - in writing.
Decide what happens on a last unit, including whether a buffer is needed.
Confirm credentials are stored as secrets and that a rotation plan exists.
Budget the daily reconciliation job - it is not an extra.

Comax Integration: Connecting a Retail ERP to a Store

Key takeaways