API Introduction¶
WalletThat’s Mobile Wallet API v3 documentation is intended to be used as a guide to generate passes, generate passes by id, update pass data, get pass data, delete pass data, and get pass templates. API calls are listed below for each of the following pass types: Gift Cards, Boarding Passes, Event Tickets, Loyalty Cards, and Coupons. Each API call listed below will show an example of a successful request and response. This documentation also provides information about error codes and the text associated with each error code as well as postback codes and their parameters. If you are experiencing difficulties while using our API, please contact our support team.
API Endpoint¶
All requests are made to the API URL which can be found in the API Settings of your account.\ Please note that future updates to our Wallet service may change the API URL. We will provide advance notice of any URL change.
Don't have an account yet?
Start a free 30-day trial to get an API URL and key. No credit card is required. API throughput is limited on the free trial; see pricing for the plans.
Definitions¶
Pass: Any mention of “Pass” in this guide refers to a Gift Card, Boarding Pass, Event Ticket, Loyalty Card or Coupon.
Pass Template: Any mention of “Pass Template” in this guide refers to a template that is created for a certain pass type and contains generic pass data.
API: Any mention of “API” in this guide refers to the API calls used to trigger the following actions: generate passes, generate passes by id, update pass data, get pass data, delete pass data, or get pass templates.
Postback: Any mention of “Postback” in this guide refers to a notification that is sent to you regarding information about your Mobile Wallet passes.
Wallet: Any mention of “Wallet” in this guide refers to the Mobile Wallet apps Apple Wallet and Google Wallet.
Date and Time Formats¶
Since 15 October 2026, all date and datetime fields in Wallet v3 API requests must be supplied in ISO 8601 format. A value in any other format is rejected with error E930, for example:
{
"status":"Failure",
"error-code":"E930",
"error-message":"The expiry-date value is invalid. Only ISO 8601 date/time format is accepted (e.g., 2026-12-31 for a date, 2026-12-31T17:30:00 for a date and time)."
}
The accepted formats are:
| Format | Example |
|---|---|
YYYY-MM-DD |
2026-12-31 |
YYYY-MM-DDThh:mm |
2026-12-31T17:30 |
YYYY-MM-DDThh:mm:ss |
2026-12-31T17:30:00 |
Either datetime form followed by Z |
2026-12-31T17:30:00Z |
Either datetime form followed by a UTC offset (±hh:mm or ±hhmm) |
2026-12-31T17:30:00-04:00 |
Fractional seconds (such as 2026-12-31T17:30:00.000Z), other separators, and offsets outside -23:59 to +23:59 are rejected. An empty string or null is not an error: it clears the field, as before.
Where a field has a companion timezone field (for example expiry-date and expiry-timezone, or link-expiration-timestamp and link-expiration-timezone), an offset in the value is accepted but ignored: the date and time are kept as written and the timezone field sets the zone. never-installed-archive-timestamp has no timezone field, so its offset is applied.
The rule covers these request fields:
- CreatePassTemplate and UpdatePassTemplate:
expiry-date,relevance-date-time,never-installed-archive-timestamp, and the date and time fields on the pass (such asevent-start-time,doors-open-time,event-end-time,boarding-time,gate-closing-time,departure-time,estimated-departure-time,arrival-timeandestimated-arrival-time). - GeneratePass and UpdatePassData:
expiration-timestamp. - CreatePassIssuanceLink and UpdatePassIssuanceLink:
link-expiration-timestamp.
Responses use ISO 8601 too, so a value read from the API can be sent back unchanged:
- GetPassData:
expiration-timestamp. - GetPassTemplate:
expiry-timestampand the date fields on the pass, asYYYY-MM-DDorYYYY-MM-DDThh:mm:ss. - GetPassTemplates and GetPassIds:
created-timestampandlast-updated-timestamp, asYYYY-MM-DDThh:mm:ssin the account's timezone.
A value that was stored with its own offset is returned with that offset.