Skip to main content

Worked wallet-passes samples

The endpoint list below documents every operation’s parameters; this overlay walks a pass ledger the way a wallet integration actually uses it: issue a pass → re-check its platform payloads → update it → void it. Success envelopes are { data, meta }, error envelopes { error, meta } — the four shapes are documented in How to read a worked sample. Run samples with a sandbox (dv_test_sk_*) key; nothing below leans on a provider-side wallet until you call the install link, and the platform endpoints then return the payloads Apple or Google Wallet consumes. Every response carries meta.request_id. Quote the request id when you report a wobble — support can trace the pass end-to-end from the ledger.

1. Issue a pass

POST /api/v1/wallet-passes/issue mints a pass into the ledger. The body is a full issueBodySchema — required type and title, optional contact_id / external_id link, colors as #RRGGBB, and up to 20 fields ( tuples). The default barcode is QR_CODE.
200
platforms.apple.configured / platforms.google.configured tell you whether your tenant’s wallet credentials are in place; the payload keys (pass_json / object / save_url) are what a mobile client.download wraps into the wallet install link.

2. Re-read the pass

GET /api/v1/wallet-passes/{id} re-issues the pass record with the platform payloads rebuilt on every read (the response below is a live payloads snapshot, not a cached one). Prefer a re-read over an issue echo when you need the current barcode or the latest status.

3. Update a pass

POST /api/v1/wallet-passes/{id}/update is the in-place rewrite the ledger exposes — send only the fields you are changing. The update echoes the fresh state including fields and colors, and it is complete (the guard at least one field must be provided rejects an empty body at 422).
200

4. Void a pass

POST /api/v1/wallet-passes/{id}/void flips the ledger to voided — the pass stops validating at a scan, the reason travels with the ledger row, and the void is idempotent-safe because the ledger keeps the original issue rows attached.
200

5. Errors

Errors follow the { error, meta } envelope. The failure every issuer hits: 422 — field validation. Colors not in #RRGGBB, more than 20 fields, or an empty update body:
422