What has been verified.
The development server was tested with an explicit read-only allowlist. No cards, discounts or locations were created, changed, deleted, allocated, verified or redeemed.
| Check | Result |
|---|---|
| Public discount search · GET and POST | 200, error=0, one returned row |
| Public geo search · GET and POST | 200, error=0, one returned row |
| Nine protected read operations · without session | 401, authentication required |
| Scalar browser client · GET and POST search | 200, error=0, one returned row |
| Desktop and mobile interface | No JavaScript errors |
| OpenAPI validation | Passed without warnings |
| Endpoint coverage and request policy tests | Passed |
Successful authenticated read responses require a development session and have not yet been verified. Write operations are documented from the manuals and deliberately untested.
Source uncertainties
- The Cards filename says v2.3, while its cover says v2.2.4.
- The legacy GraphQL-like query URL has no documented request grammar. Its POST entry is an explicitly unconfirmed placeholder.
- The manuals call IDs 24-character strings, but several current examples contain 22 characters. The schema does not enforce a conflicting length.
- The legacy discount filter named
typeconflicts with response-formattype. Prefer the explicit online/physical/international flags in GET requests. - Card JSON samples were converted from source XML. Exact authenticated response cardinality needs a session to verify.
- Nested object encoding for simplified GET writes is not fully defined. Use POST JSON for those integrations.
All examples from the manuals are illustrative. A sample response may show a different record from the corresponding request. Source context is described in the guide.