What Linet sends you over webhook when something changes

Once an endpoint is registered, Linet sends a notification every time a subscribed Item, Item Category, Account or Document is created, updated or deleted — and a webhook delivers it to you as an HTTPS POST. This walks through the payload shape and shows real notifications as Linet actually sends them.

Configuration is not self-service. There's no /create/webhook endpoint. Contact Linet support with the endpoint(s) you want notified — notifications can be filtered server-side by attribute, condition (equals / starts with / smaller than / bigger than) and value, and can fan out to multiple endpoints at once. In your request, include the endpoint URL(s), the Linet company, which objects you want (Items, Item Categories, Accounts, Documents) and any filter, e.g. "Items where category_id equals 303".

The envelope

Every notification is a single JSON object with three top-level fields. Type is reserved and normally empty, Message is a short <event>-<classname>-<sender> summary, and MessageNext carries the actual detail — this is the part you want.

Type: "",
Message: "afterUpdate-\app\models\Item-1248",
MessageNext: {
  title: "afterUpdate-\app\models\Item-1248",
  event: "afterUpdate",       // afterInsert | afterUpdate | afterDelete
  classname: "\app\models\Item",
  sender: "1248",            // id of the affected record
  model: { /* full record, same shape as the matching schema */ },
  changedAttributes: { /* only on afterUpdate — see below */ }
}

model is the record's full attribute set at the time of the event — the same shape as the corresponding Item / Itemcategory / Accounts / Docs schema in the API reference.

changedAttributes: what actually moved

On afterUpdate, MessageNext also includes changedAttributes — one entry per field that changed, each an { old, new } pair. It's the cheap way to react only to the fields you care about instead of diffing the full model yourself.

changedAttributes: {
  saleprice: { old: "0.00", new: 749.9 },
  category_id: { old: 0, new: "303" }
}

Which objects fire, and when

classname	afterInsert	afterUpdate	afterDelete
\app\models\Item	Yes	Yes	Yes
\app\models\Itemcategory	Yes	Yes	Yes
\app\models\Accounts	Yes	Yes	Yes
\app\models\Docs	Yes	Yes	No

Documents don't fire afterDelete — draft deletions aren't notified.

Example: a new item

A trimmed afterInsert notification for a newly created item — changedAttributes is absent, since there's nothing to diff against on insert.

Type: "",
Message: "afterInsert-\app\models\Item-434",
MessageNext: {
  title: "afterInsert-\app\models\Item-434",
  event: "afterInsert",
  classname: "\app\models\Item",
  sender: 434,
  model: {
    id: 434,
    name: "Ultraboost 5",
    sku: "83884",
    category_id: "0",
    currency_id: "ILS",
    saleprice: 0,
    active: 1
    // … the rest of the Item schema
  }
}

Example: an item updated

The same item a moment later, after its price and category were set. Note changedAttributes only lists saleprice and category_id — everything else in model is just the current state, unchanged.

Type: "",
Message: "afterUpdate-\app\models\Item-434",
MessageNext: {
  title: "afterUpdate-\app\models\Item-434",
  event: "afterUpdate",
  classname: "\app\models\Item",
  sender: "434",
  model: {
    id: "434",
    name: "Ultraboost 5",
    sku: "83884",
    category_id: "303",
    currency_id: "ILS",
    saleprice: 749.9,
    purchaseprice: 120
    // … the rest of the Item schema
  },
  changedAttributes: {
    saleprice: { old: "0.00", new: 749.9 },
    category_id: { old: 0, new: "303" },
    purchaseprice: { old: "0.00", new: 120 }
  }
}

Field types can shift between notifications. The same id arrives as 434 on insert and "434" on a later update — Linet doesn't guarantee a fixed type per field across events, so parse defensively rather than assuming a schema-strict type on the wire.

Delivery: what is and isn't guaranteed

Notifications are sent from a background queue a few seconds after the change is saved, as a JSON POST with the user agent Mozilla/5.0 (compatible; LinetAPI/1.0;). Build your receiver around these facts:

Question	Answer
Are requests signed?	No. Put a long random token in the endpoint URL (e.g. `/hooks/linet/3f9c…`) and reject requests that don't carry it.
Are failures retried?	No. If your endpoint is down, times out (60 s) or returns an error, that notification is lost.
What should I respond?	Any 2xx, quickly. Linet doesn't read the response. Queue the work and return.
In order?	Not guaranteed. Use `MessageNext.model` as the current state rather than replaying `changedAttributes` in arrival order.

Reconcile on a schedule. Because a missed notification is never resent, pair webhooks with a periodic search using since — e.g. POST /newsearch/item with {"since": "<last run>", "limit": 500} — to pick up anything that slipped through.

Previous← Tax Authority tax certification Back toAll journeys