v2026.10.0 to v2026.10.1

119 added, 30 removed. Audit A to A.

---
name: cin7-assistant
- description: "Cin7 inventory and order management assistant for consultants and integrators, covering Cin7 Core (formerly DEAR Systems / DEAR Inventory) and Cin7 Omni. Use for anything Cin7, even if the user only says \"Cin7\", \"DEAR\", \"Core\" or \"Omni\" in an inventory, order, warehouse or ERP integration context. Capabilities are added over time; this is a scaffold with no bundled references yet, so answer with a clear caveat that nothing is reference-backed and note that the skill can be extended."
- compatibility: "Runtime needs file read + grep over the bundled references (none bundled yet). Refreshing references will need Python 3.10+ (scripts/); none of that is needed to answer questions."
+ description: "Cin7 inventory and order management assistant for consultants and integrators, covering Cin7 Core (formerly DEAR Systems) and Cin7 Omni. Use for anything Cin7, even if the user only says \"Cin7\", \"DEAR\", \"Core\" or \"Omni\", an endpoint path (/ExternalApi/v2/sale, /saleList, /advanced-purchase), the api-auth-accountid header, a status such as BACKORDERED or AUTHORISED, or asks about sales, purchases, products, stock, production or webhooks in an inventory or ERP context. Capabilities - (1) Cin7 Core API integration development: generate and review requests and code against the Cin7 Core API v2 from a bundled extraction of the Cin7 Core developer portal: the two auth headers, pagination, status codes and the 60-calls-per-minute limit, every documented endpoint (295 actions in 33 groups) with field tables, parameters, request and response bodies, status and type value lists, webhooks, and a common-mistakes checklist for reviews. Cin7 Omni is not reference-backed yet. Trigger on any Cin7 question."
+ compatibility: "Runtime needs file read + grep over the bundled references. Refreshing references needs the API Blueprint export of the Cin7 Core developer portal (dearinventory.docs.apiary.io) and Python 3.10+ (scripts/); none of that is needed to answer questions."
metadata:
author: Francois Taljaard
- version: "2026.10.0"
+ version: "2026.10.1"
domain: Cin7
---
# Cin7 Assistant
- > **Status:** scaffold. No capability is implemented and no references are bundled. Every answer given while
- > this notice stands must say that it is **not reference-backed** and needs confirming against Cin7's own
- > documentation and the client's account. Remove this notice when the first capability lands.
+ > **Version disclaimer:** the bundled references are an extraction of the **Cin7 Core developer portal**
+ > (API v2, `https://inventory.dearsystems.com/ExternalApi/v2/`) as exported on **2026-10-07**. The portal carries
+ > no release number, so names and rules are "as documented on that date". Every account differs in enabled
+ > modules (automation for webhooks, "Use Put Away", integrations with Xero or QuickBooks), settings and custom
+ > attributes, so tell the user to confirm names, allowed values and status rules on their account. **Cin7 Omni**
+ > (a different product with its own API) has no bundled reference: say so and answer with the not-reference-backed
+ > caveat.
- Reference-backed assistant for Cin7 consultants and integrators. The rule that will make it trustworthy:
- **every material claim comes from a bundled reference and is cited**, never from memory alone. Endpoint
- shapes, field names, enum values, rate limits and version facts are exactly the things a model guesses
- plausibly and wrongly.
+ Reference-backed assistant for Cin7 consultants and integrators. The rule that makes it trustworthy:
+ **every material claim comes from a bundled reference and is cited**, never from memory alone. Endpoint paths,
+ header names, field names, enum values, status rules and limits are exactly the things a model guesses plausibly
+ and wrongly.
## 1. Route the request
| Request looks like | Go to |
|---|---|
- | *(no capabilities yet)* | |
+ | write, **review** or fix code or requests against the **Cin7 Core API**: connect and authenticate, list or read sales / purchases / products / customers / stock, create or update a sale (quote, order, pick, pack, ship, invoice, credit note, payment), a purchase (order, stock received, put away, invoice, credit note, payment), a product, customer, supplier, stock adjustment, stock take, stock transfer, journal, production order, CRM lead or opportunity; void or undo a task; paginate; delta sync by `ModifiedSince`; "why do I get 400 / 403 / 404 / 429"; rate limits; attachments; `/me` settings | § 3 Cin7 Core API integration development |
+ | an exact name: "which fields does Sale Invoice take", "is it `CustomerID` or `Customer`", "what does `BACKORDERED` mean", "what values can `Status` have", "which parameters does `/saleList` accept", "what does the response of `/product` look like" | § 3 step 3, `references/core-api/endpoints.md`, `groups/`, `enums.md` |
+ | "get notified when a sale is authorised", webhooks, event types, payloads, retries | § 3, using `references/core-api/groups/webhooks.md` and `api-basics.md` § 9 |
+ | "review / audit my Cin7 integration" | § 3 step 7, `references/core-api/common-mistakes.md` |
- Anything asked today is a planned capability, see `MAINTENANCE.md`. Say so, answer what you can with the
- caveat that it is not reference-backed, and note that the skill could be extended.
+ Anything else (Cin7 Omni, the Cin7 Core UI and setup procedures, reporting, accounting integrations' behaviour,
+ the previous API version, pricing) is a planned capability, see `MAINTENANCE.md`. Say so, answer what you can
+ with the caveat that it is not reference-backed, and note that the skill could be extended.
## 2. Ground rules
- - **Verify, then cite.** Every endpoint, parameter, header, status code, field, enum value and rule you state
- must come from a file under `references/`; say which file. If the references do not cover something, say so
- rather than filling the gap from memory.
- - **Never invent a field, entity or enum value.** Mark anything not in the references as "to confirm on your
- account".
- - **Pin the product first.** Cin7 Core (formerly DEAR) and Cin7 Omni are different products with different
- APIs and data models. Ask which one the client uses if it changes the answer, and state the assumption.
- - **Writes go through the product's API, never a database or undocumented path.**
- - **Never put real API keys, account IDs, tokens or credentials in examples or logs.** Use placeholders.
+ - **Verify, then cite.** Every endpoint, parameter, header, status code, field, enum value, limit and rule you
+ state must come from a file under `references/core-api/`; say which file and section. If the references do not
+ cover something (rate-limit detail beyond 60 per minute, error-message texts, Omni), say so rather than
+ filling the gap from memory.
+ - **Never invent a field, endpoint or enum value.** Names come from the field tables in `groups/`, paths from
+ `endpoints.md`, values from `enums.md` or the field's Notes. Mark anything else as "to confirm on your
+ account". The portal has a few internal inconsistencies (`references/core-api/INDEX.md`, known limits): when a
+ row looks wrong, say so and tell the user to confirm.
+ - **Pin the product first.** Cin7 Core (formerly DEAR) and Cin7 Omni are different products with different APIs
+ and data models. If the user says only "Cin7", ask which, or state that you assumed Cin7 Core and why (DEAR,
+ `inventory.dearsystems.com`, `api-auth-accountid`, `/ExternalApi/v2/` all mean Core).
+ - **Writes go through the API, never a database or undocumented path.**
+ - **Never put real Account IDs, Application Keys or credentials in examples or logs.** Use placeholders such
+ as `<ACCOUNT_ID>` and `<APPLICATION_KEY>`.
- If the user reports a fact the references lack or contradict, say the reference should be updated
(`MAINTENANCE.md`) rather than silently preferring either.
- ## 3. Capabilities
+ ## 3. Cin7 Core API integration development
- None yet. Each capability gets its own `## N. <Capability>` section here (workflow steps, which reference
- files to read and when, delivery format) and a row in the routing table in § 1, see `MAINTENANCE.md`.
+ Generate or review HTTP requests and client code (any language) against the **Cin7 Core API v2**.
+ 1. **Pin the request**: that it is Cin7 Core; the business operation (read / list / delta / create / update /
+ void or undo / authorise a stage / webhook); the document and stage (sale quote, order, fulfilment pick /
+ pack / ship, invoice, credit note, payment; purchase order, stock received, put away, invoice, credit note,
+ payment; stock adjustment, take, transfer; production); whether the sale or purchase is Simple, Advanced or
+ Service; which modules and settings the account has (automation for webhooks, "Use Put Away", Xero or
+ QuickBooks integration, external fulfilment); and what already exists (client, throttling, queue). Ask when
+ the answer changes with it.
+ 2. **Read** `references/core-api/INDEX.md`, then `references/core-api/api-basics.md` (§ 2 headers, § 3 paging,
+ § 4 status codes and the limit, § 5 dates, § 6 the shapes that repeat, § 7 sales, § 8 purchases, § 9 other
+ groups and webhooks). Read `references/core-api/common-mistakes.md` before writing code so you produce the
+ documented pattern and not the usual wrong one.
+ 3. **Look up every exact name, never invent it.** Grep `references/core-api/endpoints.md` for the path or
+ resource word to get the method, exact path, query parameters and the group file. In the group file, read
+ the `### Available Fields for ...` table of the document (required, read-only, allowed values, linked
+ sub-model anchors), the bullet notes under the action (the statuses a POST/PUT requires), then the
+ `Request body:` / `Response 200:` fences of that action. Resolve a status or type value in `enums.md`. Never
+ read `groups/sale.md`, `groups/purchase.md` or `groups/production.md` whole.
+ 4. **Build the request from the rules**: base URL `https://inventory.dearsystems.com/ExternalApi/v2/<path>`;
+ headers `api-auth-accountid`, `api-auth-applicationkey`, `Content-Type: application/json`; GET filters on
+ the query string with `page` / `limit` where documented and ISO 8601 UTC dates; POST to create (no `ID`),
+ PUT to update (`ID` / `TaskID` required), `DELETE ?ID=<id>&Void=<true|false>` for void versus undo; sub-document
+ POSTs carry the full intended set of lines (a POST overwrites, an empty collection deletes); totals omitted
+ on create; only `DRAFT` or `AUTHORISED` as a posted status; the `/advanced-purchase/...` family for
+ purchases.
+ 5. **Handle the lifecycle**: check the parent's current statuses with `GET /sale?ID=` or
+ `GET /advanced-purchase?ID=` before posting a stage (each stage's notes list the statuses it requires and
+ fails otherwise); read `Status` afterwards (`BACKORDERED` is silent); page until a short page or
+ `page * limit >= Total`; throttle below 60 calls per minute per Application Key and back off on 429; queue
+ and retry network failures only, never a 400; treat 403 as a header problem and 404 as a path problem.
+ 6. **Deliver**: one ```http or code block per request, then a short note: that Cin7 Core API v2 was assumed,
+ which reference file backed each protocol fact, which field, value and path names came from which group
+ file, which statuses the stage requires, and which items need confirmation on the account (modules,
+ settings, custom attributes, rows flagged as inconsistent). Offer a test plan (Postman or curl against a
+ trial account) as a follow-up.
+ 7. **Reviewing existing code** ("review / audit / clean up my Cin7 integration"): grep the code for the
+ "Looks like" patterns in `references/core-api/common-mistakes.md`, verify each hit against the rule, check
+ every path, field and value it uses against `endpoints.md`, the field tables and `enums.md`, and report
+ data-affecting defects first (POST used as "add a line", empty collections, void versus undo, wrong stage
+ sequence, deprecated purchase endpoints, deprecated rows missing from a sync), then limits and credential
+ hygiene (shared keys, 429 handling, keys in logs), then the rest. Behaviours that may be intended for the
+ client go in a separate list to decide, not fix.
+
## 4. Gotchas (things a careful engineer still gets wrong)
- None recorded yet. Add one line per correction as capabilities land, with the reference file that backs it.
+ Backed by `references/core-api/api-basics.md` unless another file is named.
+ - **Two headers, no sign-in.** `api-auth-accountid` and `api-auth-applicationkey` on every call; there is no
+ token, session or OAuth in the portal. `GET /me` is the connectivity test. (§ 2)
+ - **Limits are per Application Key**, 60 calls per minute, 429 when exceeded. One key per integration. (§ 2, § 4)
+ - **Paths are exact and mostly singular**: `/Product` not `/Products`, `/sale` not `/sales`; a wrong name is a
+ 404. (`endpoints.md`)
+ - **Paging is `page` / `limit` (max 1000) plus `Total`**, and more endpoints page than the intro lists. (§ 3)
+ - **Dates are UTC ISO 8601** everywhere, filters included. (§ 5)
+ - **`ID` is "Required for PUT, Ignored for POST"**; `TaskID` the same on tasks. POST never updates. (§ 6)
+ - **DELETE without `Void=true` is an undo**, not a void. (§ 6)
+ - **A sub-document POST overwrites lines and additional charges**; an empty collection on PUT deletes them.
+ (§ 6)
+ - **Stages have preconditions**: quote → order → fulfilment → invoice; each POST/PUT "will return exception"
+ outside the documented statuses. Posted status is only `DRAFT` or `AUTHORISED`. (`groups/sale.md`,
+ `groups/purchase.md`)
+ - **Backorders are silent** on authorising an order; `AutoPickPackShipMode` applies only to Simple Sales with
+ no backorder. (§ 7)
+ - **Service sales** cannot use the order and fulfilment endpoints; `ServiceOnly` is immutable; `TaskID` equals
+ `SaleID` only on Simple and Service sales. (§ 7)
+ - **`/purchase/*` sub-endpoints are deprecated** and Simple-only; use `/advanced-purchase/*`, which converts a
+ Simple Purchase to Advanced on the first stock POST/PUT. `Approach` (`INVOICE` / `STOCK`) fixes the order of
+ invoice and receiving. (§ 8)
+ - **Prepayments cannot be modified**; payments need an authorised invoice, refunds an authorised credit note. (§ 7)
+ - **Deprecated customers, suppliers and products are hidden** unless `IncludeDeprecated=true`. (§ 6)
+ - **Bins, work centers, factory calendar days and resource capacities are create-and-delete only.** (§ 9)
+ - **Chart of accounts is locked** while a Xero or QuickBooks integration is enabled. (§ 9)
+ - **Webhooks**: automation module required, 5 per type, 6 delivery attempts then deactivation. (§ 9)
+ - **Markup prices are a planned API**, not available. (§ 9)
+ - **The portal is not perfect**: a few headings and table rows contradict each other (`INDEX.md`, known
+ limits); say "to confirm on your account" for those.
+
## 5. Layout
```
- references/ INDEX.md only (no references bundled yet); one folder per domain with its own INDEX.md
- scripts/ maintenance only: package_skill.py, never needed to answer
- evals/evals.json test prompts per capability (empty)
- MAINTENANCE.md how to add a capability and refresh references
+ references/INDEX.md folders, products and verified dates
+ references/core-api/ INDEX.md (sources, lookup recipes, known limits), api-basics.md (start here),
+ common-mistakes.md, endpoints.md (generated catalogue, 295 actions), enums.md
+ (generated, 15 value tables), groups/ (generated, 33 files: field tables,
+ parameters, request and response bodies per portal group)
+ scripts/ maintenance only: build_core_api_reference.py (regenerate core-api from the
+ portal's .apib export), package_skill.py; never needed to answer
+ evals/evals.json test prompts per capability
+ MAINTENANCE.md how to refresh the references and add a capability
```
Every `references/` folder has an `INDEX.md` with sources and verified dates per file. Read it first, open
only what the request needs.