Skip to content
PassMaker

pass.json

pass.json reference with working examples

Understand required keys, pass styles, fields, colors, barcodes, relevance, and common pass.json validation failures.

By Swapnanil Dhol10 min read

What you’ll leave with

  • A pass must include all required top-level keys and exactly one primary pass style.
  • Field keys must be unique within the pass, and values should be concise enough for the selected layout.
  • Identifiers are not placeholders at signing time; they must agree with the signing certificate.

Required top-level keys

The required identity keys establish the format version, issuer, certificate relationship, and unique pass instance. formatVersion is numeric and normally 1. passTypeIdentifier belongs to the Pass Type ID certificate, teamIdentifier is the Apple Developer Team ID, and serialNumber distinguishes this pass from every other pass issued under that Pass Type ID.

organizationName and description are user-facing metadata. Write a useful description because accessibility features and system surfaces can expose it even when it is not prominent on the pass face.

{
  "formatVersion": 1,
  "passTypeIdentifier": "pass.com.example.ticket",
  "teamIdentifier": "ABCDE12345",
  "serialNumber": "TICKET-2026-0088",
  "organizationName": "Example Events",
  "description": "Admission for Example Live"
}

Pass style and field dictionaries

Declare exactly one classic style dictionary: boardingPass, coupon, eventTicket, storeCard, or generic. Boarding passes also require a transitType. Within that dictionary, arrange content into headerFields, primaryFields, secondaryFields, auxiliaryFields, and backFields.

Every field needs a stable key and a value. Labels are optional in some contexts but are usually helpful. Use dateStyle, timeStyle, numberStyle, currencyCode, and other formatting properties instead of pre-formatting machine-readable values into display-only strings.

  • Keep primary fields short and visually distinctive.
  • Use ISO 8601 date strings when Wallet should understand a date.
  • Keep field keys stable across pass updates.
  • Use back fields for terms, links, and secondary explanations.

Appearance, artwork, and barcodes

Wallet colors use CSS-style rgb(r, g, b) strings. foregroundColor controls primary text, labelColor controls labels, and backgroundColor sets the base. Always check contrast on an actual pass because artwork, translucency, and system rendering affect the result.

Use the barcodes array for modern passes and order formats by preference. A legacy barcode dictionary can support older consumers. Each barcode entry needs a supported format, message, and messageEncoding; altText is useful when staff may need to read or type the value.

"barcodes": [
  {
    "format": "PKBarcodeFormatQR",
    "message": "MEMBER-0042",
    "messageEncoding": "iso-8859-1",
    "altText": "MEMBER-0042"
  }
]

Relevance, app integration, and updates

relevantDate, locations, and beacons help Wallet decide when a pass may be useful. They are relevance hints, not guaranteed notifications. Keep location entries precise, use valid latitude and longitude ranges, and include short relevanceText where it clarifies why the pass is appearing.

A web service can register devices and deliver pass updates. webServiceURL must use HTTPS and is paired with a sufficiently long authenticationToken. If the pass connects to an iOS app, associatedStoreIdentifiers and appLaunchURL can provide the relationship and launch context.

Put it into practice

Build the JSON, then verify the package.

Use the free browser tools to turn the rules in this guide into a clean starting file and an actionable validation report.

Skip the hand-assembly.

PassMaker does every step on this page on your iPhone — field editor, artwork, manifest, PKCS#7 signing and Add to Wallet — without wiring up a signing environment.

Download on the App Store

Primary references