L Linet Developers
Home / Journeys / Create & update an item
Journey 01 · Catalog

Create an item, search for it, then update it

The pattern behind every catalog sync: write once, look before you write again. Three calls — create, search, update — cover the whole loop.

Create the item

POST /create/item Full reference →

A minimal item needs a name, a saleprice, whether that price is vatIn (VAT‑inclusive) or not, and a currency_id. sku is how you'll find it again in step 2 — always set one for anything you plan to sync.

name: "Phone",
saleprice: 5000,
vatIn: 1,
sku: "1234",
currency_id: "ILS"

The response echoes the saved record, including the new id — but don't rely on holding onto it across systems. That's what step 2 is for.

Search before you touch it again

POST /newsearch/item Full reference →

Whatever external system you're syncing from, it knows the item by its own key — usually the sku. Look it up before every update rather than caching the Linet id: it's the only way to stay correct if someone edited the item by hand in Linet in the meantime, or if your last sync run died halfway through.

limit: 100,
offset: 0,
query: {
  sku: "1234"
}

query filters are ANDed together and matched exactly per field. limit/offset page the result — treat a sku lookup as "expect zero or one row," and branch: zero rows means create, one row means you have the id to update.

Why not just create and let it fail on duplicate? Linet won't reject a second item with the same SKU on your behalf — nothing enforces SKU uniqueness at the API layer. Skipping the search step is how catalogs end up with duplicate items silently.

Apply the update

POST /update/item/{id} Full reference →

Send only the fields that changed — this is a partial update, not a full replace. Reusing the id you just found:

saleprice: 5001

That's the whole loop. The same three calls, run on a schedule or triggered by a webhook from your source system, are what most catalog integrations are, end to end.

Set opening stock

POST /update/item/{id} Full reference →

Once the item exists, you can set its stock level in a specific warehouse by adding stockSet, warehouse, and ammount to any create or update call. The server computes the delta needed to reach the target quantity and posts it as a stock movement — you hand it the absolute level you want, not the difference.

stockSet: 1,
warehouse: 115,
ammount: 50

warehouse is the account id of the warehouse (account type 8). ammount is the target absolute quantity — if the warehouse already holds 20 units, the API posts a movement of +30 to reach 50.

Find your warehouse id with POST /newsearch/account and "query": {"type": 8}.

Bonus: parent items and variants

Items with variants (size, color, …) are two-level: a parent created with isProduct: 3 holds the shared name and price; each variation is a separate item with isProduct: 0 and parent_item_id pointing at the parent.

CallKey fields
parent
isProduct: 3,
name: "Shirt",
saleprice: 90,
vatIn: 1,
sku: "1234",
currency_id: "ILS",
eavMTI1: 8,
eavMTI2: 2
variation
isProduct: 0,
parent_item_id: <id of parent>,
name: "Shirt, small, pink",
sku: "1234-s-pink",
eavMTR8: "small",
eavMTR2: "pink"

The eav* fields are attribute slots (size, color, whatever your catalog uses) — they're custom per company, so check the Item schema in the reference or your Linet admin for which numbers map to which attribute.