generated: '2026-08-22' method: derived source: >- openapi/green-check-verified-access-openapi.yaml + https://developer.greencheckverified.com/ guides and tutorials + https://greencheckverified.com/ (compliance claims) + live probes 2026-08-22 summary: >- Green Check Access conforms to OAuth 2.0 client credentials and little else that is cross-cutting. The error envelope is bespoke rather than RFC 9457, pagination is a conventional offset/limit shape rather than a named standard, and no idempotency standard is reachable. On the domain side Green Check's market — cannabis banking compliance — has no open API standard; the de facto interfaces are the state contracted track-and-trace systems (Metrc, BioTrack), which the contract does reach, but as an untyped pass-through proxy rather than a declared conformance. No certification (SOC 2, ISO 27001, PCI, HIPAA) is published anywhere on the estate. conformance: - id: oauth2 conforms: true profile: client_credentials (RFC 6749 §4.4) evidence: >- POST /auth/token accepts client_id + client_secret + grant_type=client_credentials and returns access_token, token_type=Bearer, scope[], expires_at, issued_at (3600s lifetime). Documented at https://developer.greencheckverified.com/guides/integration-overview and probed live 2026-08-22 (422 naming exactly those three required body fields). caveat: >- The OpenAPI models the scheme as apiKey-in-header rather than as an oauth2 securityScheme, so the contract does not machine-declare the flow it actually implements. - id: oauth2_scopes conforms: true evidence: >- Ten distinct scopes are declared per-operation under the access_auth scheme in the spec (service-provider:read/write, point-of-sale:read/write, crb:read, ein:read, connect-crb-to-sp:write, create-crb-api-key:write, trace, admin). See scopes/green-check-verified-scopes.yml. caveat: >- The docs' example token response shows different scope names (ServiceProviderRead / ServiceProviderWrite) than the spec's colon-delimited strings. The two published sources disagree. - id: rfc8414 conforms: partial evidence: >- https://developer.greencheckverified.com/.well-known/oauth-authorization-server returns HTTP 200 with valid RFC 8414 authorization-server metadata. It describes the developer portal's hosted MCP server (issuer auth.cloud.redocly.com), NOT the Green Check Access API. The Access API publishes no discovery document. - id: oidc conforms: false evidence: /.well-known/openid-configuration returns 404 on every host. No id_token, no OpenID Connect flow. - id: rfc9457 conforms: false evidence: >- Errors are application/json with a bespoke {name, message, status, stack, data} envelope and a {message, details{field:{message}}} validation shape. No type URI, no title, no instance, no application/problem+json anywhere in the spec. see: errors/green-check-verified-problem-types.yml - id: pagination conforms: true style: offset-limit with a metadata envelope evidence: >- {data:[], metadata:{total, limit, offset}}; limit default 1000 / max 1000; documented at https://developer.greencheckverified.com/tutorials/api-integration-workflow. Not a named standard, but consistent and machine-predictable. - id: idempotency conforms: false evidence: >- Zero idempotency headers in the contract. The only idempotency key (`external_reference_id` on Order / PostOrderRequest) sits on schemas unreachable from any path — the Orders subsystem is defined in components but exposed by no operation. see: conventions/green-check-verified-conventions.yml - id: rfc8594 conforms: false evidence: No Sunset or Deprecation headers documented; no deprecation policy published; zero deprecated operations in the spec. - id: rfc9116 conforms: false evidence: /.well-known/security.txt returns 404 on greencheckverified.com and developer.greencheckverified.com, 403 on both API hosts, and an SPA shell on app.greencheckverified.com. - id: json_api conforms: false evidence: Media type is application/json, not application/vnd.api+json; no JSON:API document structure. - id: odata conforms: false evidence: No $metadata surface, no OData query options. - id: scim conforms: false evidence: No urn:ietf:params:scim:schemas:* URN anywhere in the spec. User provisioning is a bespoke users[] array on CRB creation. - id: fhir conforms: false evidence: Not a health-data API. No CapabilityStatement. - id: mcp conforms: true profile: MCP 2025-06-18, streamable-http transport evidence: >- https://developer.greencheckverified.com/mcp answered a JSON-RPC initialize with protocolVersion 2025-06-18 and tools/list with 6 tools, unauthenticated, 2026-08-22. See mcp/green-check-verified-mcp.yml. - id: a2a conforms: false evidence: /.well-known/agent-card.json and /.well-known/agent.json return 404 (or an SPA shell on app.) on all five hosts probed. domain_standard: market: cannabis banking compliance / BSA-AML for cannabis-related businesses open_standard_exists: false finding: >- This market has no open API standard. The de facto machine interfaces are (a) state contracted seed-to-sale track-and-trace systems — Metrc and BioTrack — which are per-state government-mandated vendor systems rather than published standards, and (b) FinCEN BSA reporting (SAR/CTR), which is a filing regime with no API standard. Green Check is not penalised for the absence and no conformance is invented to fill the slot. contract_evidence: - surface: /trace/* (operationIds ProxyGet/Post/Put/Patch/Delete/Options, tag "Trace", scopes trace + admin) claim: >- The contract exposes a pass-through proxy to state contracted track-and-trace systems. This is the closest thing to a domain-standard declaration in the spec. conformance_grade: not-declared why: >- The proxy is untyped — path is a wildcard, request bodies are unconstrained, and the 200 response schema is the empty schema {}. Nothing in the contract names Metrc, BioTrack, or a version of either, so no conformance can be asserted from the contract. A consumer must read the downstream system's own documentation. - surface: POS normalization layer claim: >- 20+ point-of-sale and seed-to-sale systems are normalized behind one schema set (per-provider *TestAuth credential schemas: Alleaves, Biotrack, Blaze, Brytemap, Canix, Cova, Flourish, Flowhub, Greenbits, GrowFlow, GrowFlowWholesale, IndicaOnline, Intacct, Dutchie, Meadow, MjFreeway, POSaBIT, Proteus420, Treez, Weave). conformance_grade: proprietary-normalization why: >- This IS the product's value — a single contract across a fragmented market — but it is Green Check's own model, not conformance to a shared standard. Recorded as a capability, not a conformance award. certifications: published: [] probes: - url: https://trust.greencheckverified.com/ status: 000 - url: https://greencheckverified.com/security/ status: 404 - url: https://greencheckverified.com/.well-known/security.txt status: 404 note: >- No SOC 2, ISO 27001, PCI DSS, HIPAA or FedRAMP claim, and no trust center, was found on the marketing site, the developer portal, or any /.well-known/ path. NO `Compliance` and NO `TrustCenter` pointer is emitted. For a company whose product is producing the oversight reporting bank examiners require, the absence of any published security attestation is a notable gap — it is recorded here as a measured absence, not an inferred one. regulatory_context: note: >- Contextual only — not a conformance claim. Green Check's customers operate under the Bank Secrecy Act and FinCEN's 2014 cannabis guidance (FIN-2014-G001), which requires marijuana-limited / marijuana-priority / marijuana-terminated SAR filings and ongoing CRB due diligence. The API's onboarding-template, document, license-search and due-diligence-status surfaces are the machine expression of that regime. Green Check publishes no API-level conformance statement to it.