u

docs/api/routes/events.md

@@ -24,21 +24,36 @@ to the company at connect time).
 
 ## Signals
 
-| Signal | Emitted after successful |
-|--------|--------------------------|
-| `category` | `POST /category`, `PATCH /category/{id}`, `PUT /category/order`, `DELETE /category/{id}`, `POST /category/{id}/image`, `DELETE /category/{id}/image` |
-| `articles` | `POST /article`, `PATCH /article/{sku}`, `DELETE /article/{sku}` |
-| `article-<sku>` | `PUT /article/{sku}/weight`, `PUT /article/{sku}/prices`, `PUT /article/{sku}/eans`, `PUT /article/{sku}/categories`, `PUT /article/{sku}/brand`, `PUT /article/{sku}/images/order`, `POST /article/{sku}/image`, `DELETE /article/{sku}/image/{fullHash}` |
-| `brand` | `POST /brand`, `PATCH /brand/{id}`, `DELETE /brand/{id}`, `POST /brand/{id}/image`, `DELETE /brand/{id}/image` |
+Every SSE event uses the event name as the signal id; payloads are
+JSON and most events send an empty object `{}`. Only `brand` emits a
+richer payload.
 
-The `brand` signal carries a JSON payload `{ sender, brandId }`:
-`sender` echoes the caller's `x-client-id` header (empty string if
-absent) so the sender can ignore its own event; `brandId` is the
-affected brand id (`null` only if unknown). Other signals send `{}`.
+| Signal | Payload | Emitted after successful |
+|--------|---------|--------------------------|
+| `category` | `{}` | `POST /category`, `PATCH /category/{id}`, `PUT /category/order`, `DELETE /category/{id}`, `POST /category/{id}/image`, `DELETE /category/{id}/image`, `PUT /category/{id}/property` |
+| `articles` | `{}` | `POST /article`, `PATCH /article/{sku}`, `DELETE /article/{sku}`, `PUT /article/{sku}/articles`-style list-level changes, `POST /category/{id}/article` and related article-assigning category mutations |
+| `article-<sku>` | `{}` | `PUT /article/{sku}/weight`, `PUT /article/{sku}/prices`, `PUT /article/{sku}/eans`, `PUT /article/{sku}/categories`, `PUT /article/{sku}/brand`, `PUT /article/{sku}/images/order`, `POST /article/{sku}/image`, `DELETE /article/{sku}/image/{fullHash}`, supplier/article-property mutations affecting the article |
+| `stock` | `{}` | `POST /stock/adjust` |
+| `ledger` | `{}` | `POST /stock/adjust` |
+| `attributename` | `{}` | `POST /attributename`, `PUT /attributename/order`, `PATCH /attributename/{id}`, `DELETE /attributename/{id}` |
+| `propertyname` | `{}` | `POST /propertyname`, `PUT /propertyname/order`, `PATCH /propertyname/{id}`, `DELETE /propertyname/{id}` |
+| `labeltemplate` | `{}` | `POST /labeltemplate`, `PUT /labeltemplate/{id}`, `PATCH /labeltemplate/{id}`, `DELETE /labeltemplate/{id}` |
+| `printer` | `{}` | `POST /printer`, `PUT /printer/{id}`, `PATCH /printer/{id}`, `DELETE /printer/{id}` |
+| `warehouse` | `{}` | `POST /warehouse`, `PUT /warehouse/{id}`, `PATCH /warehouse/{id}`, `DELETE /warehouse/{id}` |
+| `vfs` | `{}` | VFS uploads and filesystem mutations such as `POST /vfs/upload`, `POST /vfs/mkdir`, `POST /vfs/rename`, `PUT /vfs/{*path}`, `DELETE /vfs/{*path}` |
+| `modelconversation` | `{}` | `POST /modelconversation`, `DELETE /modelconversation/{id}` |
+| `modelconversation-<id>` | `{}` | Conversation-specific updates on the same model conversation thread; the concrete ID is used in the event name |
+| `brand` | `{ sender, brandId }` | `POST /brand`, `PATCH /brand/{id}`, `DELETE /brand/{id}`, `POST /brand/{id}/image`, `DELETE /brand/{id}/image` |
+
+The `brand` payload is `{ sender, brandId }`: `sender` echoes the
+caller's `x-client-id` header (empty string if absent) so the sender
+can ignore its own event; `brandId` is the affected brand id (`null`
+only if unknown). All other signals send `{}`.
 
 Signals are only sent when the mutation actually succeeds (2xx).
 Failed or no-op validation errors do not emit. The `article-<sku>`
-event name uses the concrete SKU (e.g. `article-42000045`).
+and `modelconversation-<id>` event names use the concrete item id at
+runtime (for example `article-42000045` and `modelconversation-123`).
 
 
 ## Response `200`