update_template
Partially update an existing wallet template by sending only changed fields. Deep-merges pass JSON for targeted edits; replaces locations array wholesale. Note: design changes apply only to passes issued after the update.
Instructions
Partial update of an existing template (RFC 7396 merge-patch semantics). Send only the fields you want to change. Updating pass deep-merges with the existing pass JSON, so you can change a single color or add a field without round-tripping the whole pass. locations is the exception: it REPLACES the stored array wholesale (send the full set; [] clears them), because merging geofences by index would strand stale ones. ALREADY-ISSUED PASSES: a stored .pkpass is not rebuilt on every read, so design and artwork changes reliably show up only on passes issued AFTER the update. Verify a change by issuing a fresh pass rather than re-downloading an existing one.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| pass | No | Pass design overrides. Most useful keys: backgroundColor, textColor, labelColor, logo, hero, icon, strip, rows, linkRows, header, barcode, nfc. Inside rows / linkRows / header you can send field shorthand like { id: "memberName", label: "Member" } — the server fills fieldValue, name and (for known ids like balance) googleId. Image fields accept either { preview: "https://…" } or { fileId: "file_…" } from POST /files. STAMP CARDS (loyalty): set `useStampCollection: true`, `stampCount: <n>`, `stamp: { fileId }` (icon — `purpose: 'template_stamp'`), AND `hero: { fileId }` (REQUIRED — the wide banner that stamps are composited onto as a dimmed background, `purpose: 'template_hero'`). Without `hero` the server skips banner generation and the pass shows no stamps. Both images must be supplied for stamps to render. VALUES: every `fieldValue: 'custom'` block — in `header`, `rows` and `linkRows` alike — is filled at issue time from `templateFields[id]` on create_pass. Do not put display values in the template itself. APPLE STRIP: Apple's banner is generated from the hero you supply here; if you supply none, the pass falls back to a stock per-type image that will not match the business. Supply a `hero` fileId for any customer-facing template. ICON: ALWAYS supply one, sourced from the business's own website — omit it and the pass ships the WALLETAP logo, which is the most visible way for a customer's card to look unfinished. Their icon is declared in their HTML; prefer `<link rel="apple-touch-icon">`, then the largest `<link rel="icon" sizes=…>`, then `msapplication-TileImage`, and take the biggest square available (a 32px favicon upscaled to 87px is mush). Then CHECK IT AGAINST THE CARD: favicons are drawn for browser tabs and are usually a dark mark on transparency, which vanishes on a dark pass. When that happens, keep their glyph but set it on a filled disc in their brand colour with the mark knocked out in white — legible at 29px, and safe under Google's circular mask. WEB LINK: `webApp` is the business's site (a full https URL is fine) and `webAppLabel` is what Google Wallet calls that row. Without a label the row is named after the pass title, which tells the holder nothing about where it goes — write e.g. 'ACME website'. Omit `webApp` rather than guessing a URL; a row that leads nowhere is worse than no row. | |
| beacons | No | ||
| passPage | No | ||
| enableNFC | No | ||
| locations | No | ||
| enrollForm | No | ||
| templateId | Yes | Template id. | |
| cardSharing | No | ||
| enableBarcode | No | ||
| requireAuthentication | No |