classification: internal type: wiki status: active date: 2026-04-25 last-compiled: 2026-04-25 needs-review: 2026-05-09 source: github.com/NCRCounterpointAPI/APIGuide v2.4 (cloned)

NCR Counterpoint API — Endpoint × CRDM × Spine Map

Governing thesis

The Counterpoint REST API surface is dominated by three things — customer master, item master, and document (transaction) — and almost everything else is plumbing or thin metadata around them. Mapped to Canary's CRDM classes and the spine letter scheme used in the Counterpoint integration SDD, the 95 documented endpoints (97 files minus 2 stubs) cluster unambiguously around T (Transactions), C (Customer), S (Space / Range / Display), F (Finance), and N (Device). Modules L (Labor) and W (Execution) have zero coverage from this surface and must be sourced elsewhere or deferred.

This article is the per-endpoint detail companion to docs/sdds/canary/ncr-counterpoint-retail-spine-integration.md §4–§6. The SDD asserts module groupings at the endpoint-family level; this article checks that assertion endpoint-by-endpoint and flags the few places where the per-endpoint reading argues for a different module than the SDD's family-level reading.

It is not a redefinition of the spine letter scheme — that lives in Brain/wiki/retail-integration-spine.md (canonical C / D / F / J / S active; P / R placeholder) and is extended by the SDD with L Labor, W Execution, plus letters T / R / N / Q / A / C that the SDD uses to address Canary's own module decomposition. Where the SDD letters diverge from the canonical spine wiki, the SDD is the operative scheme for this Counterpoint engagement; the divergence is itself flagged in the gap report below.

Method

For each of the 97 endpoint files in Brain/raw/inbox/rapid-pos/ncr-counterpoint-api/Endpoints/:

1. Read method + path verbatim from the file header (or README chart where the file header is generic).
2. Identify the dominant Counterpoint table prefix (AR_CUST, IM_ITEM, PS_DOC_HDR, PS_STR, EC_*, SY_*).
3. Map to a CRDM entity class: People · Places · Things · Events · Workflows · platform.
4. Assign a spine module letter from SDD §4 — or platform for endpoints that exist purely to operate the API server (APIKey, AdminUser, Database, Role, SystemInfo).

Mapping table

Endpoints are grouped by resource noun. Two source files (GET_Customer_Address.md, GET_Customer_Note.md) are header-only placeholders with no documented endpoint and are listed here for inventory completeness, marked (stub-only). Total rows: 97 (95 real + 2 stub).

Platform — system administration

Platform — authorization (Roles, Users)

Customer — module C

Document — module T (with F and Q downstream)

Item / catalog — module S (with A as derived view)

Inventory — module D (with cost slice in F)

Vendor — module M / J seam

Store / device — module N

Tokenization — module F (Secure Pay tender)

Pay codes / tax — module F

Gift card — module F (tender) with S (catalog code template)

eCommerce — module S (with R for customers, F for tender via NSP)

Workgroup — module C (template-driven defaults)

Coverage gap report

Spine modules with rich Counterpoint coverage

• T (Transactions) — 10 endpoints. PS_DOC_HDR + nested PS_DOC_LIN / PS_DOC_PMT / PS_DOC_NOTE / PS_DOC_TAX / contacts. Full read + write. Adequate for Canary's core fact feed.
• C (Customer) — 18 endpoints (16 real + 2 stub). AR_CUST + ship-to
• notes + cards + open items + control + workgroup-driven defaults. Best-covered domain in the API.
• S (Space / Range / Display) — 9 endpoints. Item master, categories, serials, images. eCommerce control + categories add 2 more. Adequate for catalog sync.
• D (Distribution) — 6 endpoints. Per-location inventory, control block, locations list, item-cost-by-location. Adequate for SOH + per-location reads. No transfer endpoints exposed — transfers must be derived from PS_DOC_HDR with transfer-typed DOC_TYP.
• F (Finance) — ~12 endpoints across pay codes, tax codes, gift cards, tokenization, NSP transactions, plus payment slice of Document. Adequate for tender / tax / Secure-Pay closing of the loop.
• N (Device) — 3 endpoints (Store, Station, DeviceConfig). Sufficient for the device-inventory side of the spine.

Spine modules with partial / derived coverage

• A (Asset Management) — 0 dedicated endpoints. Per SDD §6.4 derived from GET /Items filtered on a non-saleable / asset flag. Schema dimension ITEM_TYP (I = inventory, N = non-inventory) is the most likely discriminator; explicit asset flag was not visible in the sample-derived schema and remains an SDD §6.4 open question.
• C (Commercial) — 0 dedicated endpoints. Derived from GET /Customers filtered on CATEG_COD / ALLOW_AR_CHRG / multi-tier indicators on AR_CUST_CTL, plus GET /Customer/{CustNo}/OpenItems for B2B AR. SDD §6.6 open questions remain.
• J (Forecast / Order) — 1 dedicated endpoint (/VendorItem/{VendorNo}/Item/{ItemNo}). No PO / replenishment / forecast endpoints in this corpus. Confirms SDD §6.9 open question: Counterpoint's replenishment engine appears UI-only at v2.4.
• P (Pricing / Promotion) — 0 dedicated endpoints. Pricing fields exist on IM_ITEM (PRC_1, REG_PRC, PREF_UNIT_PRC_1) and on AR_CUST_CTL (multi-tier flags). Promotions and effective-dating endpoints absent. Aligns with SDD §6.11 — deferred until Counterpoint exposes promotion endpoints or until a separate pricing system is integrated.
• Q (Loss Prevention) — 0 dedicated endpoints. Not a gap — Q is Canary-internal per SDD §6.5; consumes T+R+L+N substrate. The point of Q being last in phasing is that Counterpoint doesn't surface it.

Spine modules with NO coverage

• L (Labor) — 0 endpoints. The corpus exposes API-server roles + users (treated as platform above), NOT Counterpoint employee records, timeclock, or scheduling. Confirms SDD §6.12 open question. Must be sourced from a separate workforce module or deferred.
• W (Execution) — 0 endpoints. No task / checklist / workflow surface. Confirms SDD §6.13 — must be sourced elsewhere.

Discrepancies flagged

File-count discrepancies:

README chart vs. source-file discrepancies:

1. README chart's Document_Note POST hyperlink points to PUT_Document_Note.md instead of POST_Document_Note.md.md — broken link.
2. README chart row for /Document/{DocId}/Contact PATCH actually links to a file named PUT_Document_Contact.md and the file's header reads PUT /Document/{DocId}/Contact. Method label inconsistency (chart says PATCH, file says PUT).
3. README chart row for /PayCode/{Paycode} PATCH links to PUT_PayCode.md whose header reads PUT /PayCode/{Paycode}. Same pattern as #2.
4. README chart references GET_Paycode.md and GET_Paycodes.md (lowercase variants); actual files are GET_PayCode.md and GET_PayCodes.md (mixed case). Filename casing inconsistent with chart.
5. README chart row for /Customer/{CustNo}/Card POST has source file header POST /customer/{custNo}/CARD (all-different casing). Counterpoint REST routing is presumably case-insensitive but this is editorial drift in the docs.
6. GET /DeviceConfig/{WorkstationID} exists as a file but is missing from the README chart.
7. README chart shows CompanyAdmins/{CompanyName} (no leading slash) for some rows; OpenAPI normalizes to /CompanyAdmins/{CompanyName}.

SDD vs. per-endpoint detail divergences:

1. SDD §4 puts InventoryLocations under Places (N). Per-endpoint reading argues D (Distribution) is the operative module — the endpoint feeds inventory-by-location semantics, not site/device inventory. Both are defensible; we map to D in this article and flag.
2. SDD §4 People row includes "AdminUser, Roles" under module R (Customer) with module L* as cross-reference. Per-endpoint reading: Admin/Roles/Users are API-server platform concerns, NOT customer or labor entities — they should be platform not R or L. This article maps them to platform and flags.
3. SDD §4 Things row puts GiftCard* under S, A, P. Per-endpoint reading argues F primary (gift card = tender) with S secondary for the code template only. This article maps F+S and flags. The SDD's "P" attribution for gift cards is hard to justify from the endpoint surface and is likely a remnant of an earlier draft.
4. SDD §6.12 Module L cites Roles, RoleUsers, RolesUsers, RoleEndpoints as candidate endpoints — but the SDD itself flags these as "API-level roles, not labor-level". This article confirms: there is no labor surface in this API. L coverage = 0.
5. SDD letter scheme overlaps with but does not match the canonical spine wiki. The canonical wiki has C / D / F / J / S active; the SDD additionally uses T (Transactions), C (Customer), N (Device), Q (Loss Prevention), A (Asset), P (Pricing), L (Labor), W (Work Execution). For this engagement the SDD's expanded scheme is operative, but a future reconciliation pass should either fold the SDD letters into the canonical wiki or document why Canary's internal module decomposition diverges from the canonical spine catalog.

Related

• docs/sdds/canary/ncr-counterpoint-retail-spine-integration.md — the SDD whose §4–§6 this article checks endpoint-by-endpoint.
• docs/sdds/canary/ncr-counterpoint-openapi.yaml — the OpenAPI 3.0 rendering of the same surface.
• Brain/wiki/retail-integration-spine.md — canonical spine letter scheme (C / D / F / J / S active; P / R placeholder).
• Brain/wiki/ncr-counterpoint-connection-runbook.md — bring-up runbook companion.
• Brain/raw/inbox/rapid-pos/ncr-counterpoint-api/ — source corpus.