How long does NMS2S API validation take?

The package sets no timeline. The sequence is fixed — request, Terms, UAT, remediation of any Material Issue, attestation, token — and CCD and Real Time Solutions review the UAT results, so the pace depends on their queue and on how many functions a partner requests. Requesting only the functions you will use keeps the scenario list short.

What is a Material Issue?

An error, defect or other problem found in required testing that prevents or materially interferes with using the API functionality as documented and intended. A request for an endpoint, field or workflow that isn't in the documentation is explicitly not a Material Issue.

Is the UAT token the same as the production token?

No. UAT uses a UAT-specific IP token that does not reach production. The production Integrator Bearer Token is a separate credential issued only after CCD and RTS confirm every step is complete.

Does passing validation mean the state certified the software?

No. The procedure says in terms that completion 'does not constitute CCD, RLD or RTS approval, certification, endorsement, or warranty' of the partner's software. Any vendor who says New Mexico certified their NMS2S integration is overstating it.

NMS2S for New Mexico retailers

How to get NMS2S expanded API access: CCD's validation process, step by step

What New Mexico's Cannabis Control Division requires before it issues a production Integrator Bearer Token for the NMS2S expanded API — the request form, the Terms, UAT in a Fixture organization, the validation scenarios for each function, the readiness attestation, and what the Terms oblige an integrator to do in production.

By BudAlly

Published Oct 8, 2026Reviewed Oct 8, 2026 by Regulatory counsel (advisory)

Summarised from CCD's September 30, 2026 package in our own words. The package is a procedure, a set of Terms and three forms; the API documentation itself is given to partners in UAT and the Terms prohibit sharing it, so you will not find endpoints here or on any vendor's site. Not legal advice; the package is authoritative.

The six steps

Step	What happens	Document
1. Request	The partner names its organisation, every product that will use the token, a business and a technical contact, the functions it wants (check-boxes), and its intended use	Exhibit 1 — Access Request Form
2. Terms	The partner accepts the Expanded Production API Access and Use Terms and Conditions; Exhibit 1 is incorporated into them	Document Two
3. UAT	CCD and RTS provide a UAT-specific IP token and a test organisation (a "Fixture") with locations, rooms, plants and inventory. The Fixture does not include the NMS2S UAT web application	Procedure §3
4. Validation	The partner demonstrates each requested function against CCD's scenarios; CCD and RTS review; any Material Issue is fixed and re-tested	Exhibit 2 — UAT Validation Form
5. Attestation	The technical contact attests to UAT completion, Material Issues resolved, production consistency with what was tested, idempotency implemented and tested, and authorised use only	Exhibit 3 — Production Readiness Attestation
6. Token	RTS confirms the technical requirements; a production Integrator Bearer Token is issued, separate from the UAT token	Procedure §6

Submitting the form and accepting the Terms do not by themselves grant UAT or production access. Each function requested is validated; access to a function not validated is not authorised. Material changes to the API or to the partner's integration can trigger re-testing.

The functions you can request

Inventory and plant information: inventory at an authorised location; an inventory item by NMS2S inventory ID; an inventory item by barcode; plants at an authorised location; a plant by NMS2S plant ID; a plant by barcode.

Inventory actions: split an inventory item; adjust an inventory item; change the product name associated with an inventory item.

Where ID and barcode are alternative ways to retrieve the same thing, a partner validates only the method it will use in production.

What each scenario checks

Reads (1–4): retrieve for an authorised location; correctly receive and process the response; for ID and barcode lookups, handle an invalid or nonexistent identifier appropriately.
Split (5): submit an authorised split with the right quantity; process the success response; receive the new inventory ID(s) and barcode(s); confirm the original quantity and the new records are correct in NMS2S; handle a split that violates a validation or business rule; generate and submit the required idempotency key; resubmit with the same key and confirm it is not processed twice.
Adjust (6): submit with quantity and the required adjustment reason; confirm the resulting quantity and the entry in the item's inventory history; handle a rejection; idempotency as above; and, when no confirmation is received, make a reasonable effort to determine whether the transaction processed before resubmitting.
Product name (7): submit the change; confirm it on the item; handle a rejection.

Each scenario is marked Pass, Fail, Not Requested or Retest Required.

What the Terms require in production

Token hygiene. Protect the token; restrict it to personnel who need it; never sell, transfer, publish or disclose it; use it only with the products listed in Exhibit 1; notify CCD of additional products before using the token with them; report any suspected loss or compromise promptly.
Licensee authorisation. The token does not by itself authorise access to any licensee's records. The partner may reach a licensee's data only with the authorisation and credentials NMS2S requires for it, and may never use one licensee's or location's credentials to reach another's.
Data use. Retrieve, transmit, process and store NMS2S data only as reasonably necessary to provide the authorised functionality; keep reasonable administrative, technical and physical safeguards; never pull data unrelated to the licensees and locations you serve.
Transactions. NMS2S remains the system of record. Writes follow the API specification and NMS2S validation. Never represent a transaction as completed when NMS2S rejected it or no sufficient confirmation arrived. Every create, modify or delete carries an idempotency key; retries reuse it; a new transaction gets a new one; never mint a fresh key to resubmit a change that could duplicate a record. Never circumvent NMS2S validations, business rules, access controls or duplicate-transaction protections.
Security and incidents. Notify CCD within 24 hours of discovering a suspected or confirmed credential compromise, unauthorised access through the partner's systems, material misuse of the API, a security incident materially affecting NMS2S data, or a technical issue in the partner's system that caused or could cause inaccurate NMS2S records; keep CCD updated; cooperate with CCD and RTS.
Prohibited. Circumventing access controls; using functions not authorised; malicious code; penetration or vulnerability testing against NMS2S; excessive or abusive traffic; use inconsistent with CCD's or RTS's technical requirements; sharing API documentation or tokens with other parties.
No endorsement. Validation and a token are not approval, certification, endorsement or warranty by CCD, RLD or RTS of the partner's software or of anyone's compliance; licensees remain responsible for the accuracy and completeness of what is reported.
Suspension, change and availability. CCD may suspend, restrict or revoke access for credential compromise, prohibited use, security concerns, repeated inaccurate records or non-compliance, and may require corrective action before restoring it. CCD and RTS may modify, add to, restrict or discontinue API functionality, with notice when practicable; partners maintain their integrations to current requirements, and successful validation of one function never authorises a future one. The API may be unavailable; the partner must handle unavailability, failed requests and interrupted transactions. Access is non-transferable; obligations on data protection and incidents survive termination.

What to ask any vendor who says "we're integrated with NMS2S"

Which tier — the retail POS API, the expanded API, or both — and which functions did you validate?
Where is your idempotency key stored, and can I see it on the record of an adjustment?
When NMS2S didn't confirm a write, what did your software do next?
Did you deploy what you tested in UAT, or something broader?
Will you confirm in writing that validation is not state certification?

How BudAlly maps to this

Every NMS2S write in BudAlly is a proposal: drafted by an agent with the idempotency key assigned at draft time, approved by a named person, executed once, verified by a read-back, and recorded with the key, the reason, the response and the resulting quantity. A rejected or unconfirmed write stays open and visible until the read-back settles it; nothing marks itself done. Token and licensee credentials live in a secrets vault with per-location scoping. Those are our controls regardless of state; the New Mexico Terms happen to require them. The NMS2S API page · BudAlly in New Mexico.