Operation Log
0 ops
No operations yet. Click Issue £50 to begin.
Raw Protocol Trace
Last operation
// No trace yet
Findings — MTK/MintPass API Analysis
ENTITLELAB-01
These findings describe behaviour observed by ENTITLELAB-01 while integrating against the live MintPass sandbox API. They distinguish live API behaviour from local UI assumptions and are intended to guide ENTITLELAB-02 Local Mode work.
1. What did the MTK/MintPass API support cleanly?
Container creation, entitlement issuance, lifecycle transition, and consume with
mode: DRY_RUN | COMMIT are supported by the live MintPass sandbox API. Container creation is a required prerequisite for entitlement issuance and must include external_ref (or policy_number) plus product_type; missing these fields produces a blocking 400 before entitlement issuance begins. Idempotency keys are natively supported on /consume. In the current EntitleLab integration path, live evaluation is performed through /consume using DRY_RUN — this allows the simulator to run the same gate as COMMIT without mutating ledger state. The available GET evaluation surface did not behave as a live mutation gate during this experiment.
2. What could be safely derived from current API responses?
Remaining balance from
remaining_quantity on the entitlement response. Ledger event count from ledger_event_count. Lifecycle state from lifecycle_state_canonical (authoritative protocol lifecycle state) vs state (domain/workflow state — do not conflate). Constraint reasons from a blocking array in the evaluation response payload. Idempotency replay safety from ledger count delta (0 on replay confirms no double-consumption). Minor-unit normalization: £50 = 5000, £20 = 2000, £40 = 4000.
3. What had to be mocked locally?
Nothing was mocked. All operations hit the live MintPass sandbox API. The consume response on DRY_RUN returns the same evaluation outcome as COMMIT without writing a ledger event — this is a first-class API feature, not a simulation. Tenant consistency: issue and consume must use the same tenant context — cross-tenant consume is not supported.
4. What would need to become a future MTK primitive for Local Mode or offline use?
Candidate future primitives or design areas for Local Mode include: (a) signed or verifiable offline evaluation evidence — a credential the POS can check without a network round-trip; (b) a local ledger sync protocol for replaying and verifying ledger events offline; (c) delegated local authority for offline commits that can be queued and replayed with guaranteed idempotency on reconnect; (d) cache freshness rules and conflict handling; (e) capacity reservation or anti-double-spend safeguards. ENTITLELAB-02 should test these as design questions, not assume they already exist as MTK protocol primitives.
5. What currency/denomination convention was observed?
MintPass uses minor units (pence) throughout.
consumable_spec.initial_quantity and remaining_quantity are in pence. £50 = 5000, £20 = 2000, £40 = 4000. All display values in this UI divide by 100. The unit_code: "GBP" and unit_type: "currency" fields confirm denomination. No ambiguity observed — the API is consistent.
6. What API capabilities were missing or unclear from public docs?
(a) Cross-tenant consume: Entitlements issued under the itinerary sandbox tenant (55000000) cannot be consumed using evaluation sandbox credentials (b0000000). Both issue and consume must use the same tenant context. (b) Lifecycle activation: Issued entitlements begin in
ISSUED state and require a POST /api/lifecycle/transition to ACTIVE before consume can pass the lifecycle dimension. (c) Container required: Entitlements cannot be issued without a parent container — no bare-issue path exists. (d) Container creation fields: POST /api/containers requires external_ref (or policy_number) and product_type; omitting these produces a blocking 400.