Skip to content

NMS2S for New Mexico retailers

The NMS2S API for dispensary software: what exists, what it supports, how access works

New Mexico's NMS2S has two API tiers now: the retail POS API (sales, deliveries, patient validation, voids) and, since September 30, 2026, an expanded API for inventory and plant reads, splits, adjustments and product-name changes that any integration partner can apply for through CCD's validation process. What each covers, what is still manual, and how the token model works.

By BudAlly

Published Reviewed by Regulatory counsel (advisory)

As of October 8, 2026. The retail POS API section is assembled from state bulletins and from Dutchie, Flowhub and GrowFlow help articles. The expanded API section is from CCD's NMS2S Expanded API Access and Validation Package dated September 30, 2026, which sets out the access procedure, the production Terms and the validation scenarios — not endpoint documentation, which is supplied to partners in UAT and which the Terms do not allow us to republish. We describe the procedure in our own words.

Two tiers

Retail POS APIExpanded API (Sept 30, 2026)
WhoPOS providers, materials distributed before launchAny third-party integration partner that completes CCD's validation
CredentialPer-location token created by the licensee's Org Admin (Locations → Create Token)A UAT-specific IP token for testing, then a separate production Integrator Bearer Token issued to the partner — plus licensee authorization for each licensee served
FunctionsSales (dispense), delivery dispense, patient validation and 90-day allotment, whole-ticket voids; reads of Sales Floor inventory and lab resultsReads: inventory at a location, item by inventory ID, item by barcode, plants at a location, plant by ID, plant by barcode. Actions: split item, adjust item (quantity + reason), change product name
GateVendor relationship with RTS/CCDExhibit 1 request → Terms → UAT in a Fixture organization → Exhibit 2 scenarios passed → Exhibit 3 attestation → token

What is now possible for a non-POS layer

Reads of inventory by location, by ID and by barcode mean the system side of a reconciliation can be pulled instead of exported: NMS2S quantities by item, compared to the physical count and to the POS, every night. Adjustments and splits mean the correction can be submitted through the API after a person approves it, with the adjustment reason recorded and the result read back. Product-name changes cover the most common migration fix.

What is still manual in the web app

Room creation and moves to Sales Floor; transfers and manifests (create, receive, void); item-level refunds and partial returns; destruction, remediation and retests; the tax amount on every ticket (entered, not computed); adult-use purchase-limit enforcement; driver, vehicle and user management; delivery agreements. None of these appear in the expanded API's request form. BudAlly turns them into a checked task list with the NMS2S screen linked from each step.

What the production Terms require of an integrator — and why it matters to you

  • Idempotency keys on every create, modify or delete. Retries of the same transaction reuse the same key; a new transaction gets a new key. An integrator may not mint a new key to resubmit the same change when that could duplicate a record. (BudAlly: every proposal carries its key from draft, and the key is in the audit trail.)
  • No claimed success without confirmation. If NMS2S rejects a request or the integrator never receives confirmation, the integrator may not represent the transaction as completed and must check with the API whether it processed. (BudAlly: the verification field on every executed proposal is the read-back from NMS2S.)
  • Licensee authorization per licensee. The token is the partner's; the data is yours; access requires the authorization and credentials NMS2S asks of you, and must stay within the locations you authorized.
  • Data use limited to the integration. Retrieve, process and store NMS2S data only as reasonably necessary to provide the authorized functionality; reasonable administrative, technical and physical safeguards.
  • Incident notification within 24 hours to CCD of a suspected credential compromise, unauthorized access, misuse, a material security incident, or a technical issue that could cause inaccurate NMS2S records.
  • Not an endorsement. UAT validation and a production token do not constitute CCD, RLD or RTS approval, certification or warranty of the partner's software — or of the licensee's compliance, which stays with the licensee.
  • CCD can change the API, require re-testing after material changes on either side, and suspend or revoke access. Access is non-transferable.

Identifiers

NMS2S inventory ID (numeric; BioTrack-era IDs preserved in migration) and NMS2S barcode. The validation form treats ID and barcode as alternative retrieval methods: a partner validates only the method it intends to use. Splits return the newly created inventory ID(s) and barcode(s), which answers the parent–child question for API-created splits; linkage for splits made in the web app is still to be confirmed in UAT.

Open questions (carried into UAT)

  1. Whether one production Integrator Bearer Token plus a licensee's per-location token is the full credential pair for reads, or whether licensee authorization is granted inside NMS2S by Org Admins.
  2. Rate limits, polling cadence, and whether any push notification exists (the package is silent; we assume pull).
  3. Whether transfers, manifests, room moves, refunds, destruction or tax computation will join the expanded API, and when.
  4. Whether a persistent sandbox beyond the UAT Fixture is available for regression testing after production access.

Helpline 505-524-0940 (Mon–Fri 8–5 MT) · support portal ccdprod.rtsclients.com/support-request.html · rtsolutions.com/s2s-support.

BudAlly's NMS2S adapter today: NMS2S exports + POS data, nightly reconciliation, per-ticket tax computation, manual steps as a task list; expanded-API reads and approved adjustments as soon as validation completes. How CCD's validation works · New Mexico page.

Sources

  1. NM RLD — NMS2S · 2026–09
  2. CCD — NMS2S Expanded API Access and Validation Package (Procedure, Terms, Exhibits 1–3) · Sep 30, 2026
  3. RLD Bulletins 26-08, 26-09, 26-11, 26-16 · 2026–08
  4. NMS2S Migration Guidance (PDF) · 2026–08
  5. Dutchie / Flowhub / GrowFlow NMS2S help articles · 2026–09
  6. 16.8.2.40 NMAC · 2026

Questions

Can a company that isn't a POS get NMS2S API access?
Yes, for the expanded API. CCD's September 30, 2026 package is addressed to 'third-party integration partners' generally. The partner files an access request (Exhibit 1) listing its products and the functions it wants, accepts the production Terms, passes UAT scenarios in a state test organization, signs a readiness attestation, and is then issued a production Integrator Bearer Token. The retail POS API (sales, voids) was distributed to POS providers separately.
What does the NMS2S expanded API let software do?
Read inventory at an authorized location, an inventory item by NMS2S inventory ID or by barcode, plants at a location, a plant by ID or barcode; and perform three actions — split an inventory item, adjust an inventory item (quantity plus a required reason), and change the product name on an inventory item. Every write needs an idempotency key.
Does an integrator token give access to my store's data?
No. The Terms say an Integrator Bearer Token 'does not independently authorize access to a licensee's NMS2S information or records.' The licensee still has to provide the authorization and credentials NMS2S requires for that access, and a token tied to one licensee or location cannot be used to reach another.