Build on Walletap

The three ways to connect your own systems to Walletap, when to use each, and the conventions every API request follows.

Web

Everything you do in the dashboard — issuing a pass, adding a stamp, sending a notification — your own software can do too. Walletap offers three ways in, and they all act on the same account, the same templates and the same passes.

Paid plans

Three ways in#

You want to…	Use	Because
Issue and update passes from your own app, website, booking or POS system	REST API	Full control, any language, runs inside your code
Connect a form, CRM or spreadsheet without writing code	Automation platforms	A workflow on the platform calls Walletap for you
Ask an AI assistant to design a template or look up a member	AI assistants	The assistant calls Walletap's tools on your behalf

REST API#

The API is what the other two are built on. Your server sends HTTPS requests with an API key and gets JSON back. Use it when Walletap is one step inside a process you already run: a customer signs up on your website, pays at your till or books a class, and your system issues or updates their pass in the same moment.

Start with Issue your first pass, which takes about ten minutes with nothing but a terminal.

Automation platforms#

No-code automation platforms connect to Walletap with an API key, either through Walletap's published app on the platform or through the platform's own HTTP step calling the REST API. Connecting one takes a single click in SettingsIntegrationsAutomation: Connect creates an API key labelled with the platform's name and shows it to you once to paste into the platform. The key can manage passes and, on accounts with access badges, issue them. Disconnect turns that key off.

See Integrations for each platform's actions and setup.

AI assistants#

Walletap runs an MCP server at https://mcp.walletap.com. AI assistants that speak MCP connect to it, you sign in to Walletap once to approve the connection, and from then on the assistant can design templates, issue passes and answer questions about your members. No API key is involved.

See AI assistants to set one up.

How the API works#

Base URL and paths#

Every endpoint lives under one host:

Shell

https://api.walletap.com

Paths are short and resource-shaped: /pass for one pass, /passes for lists of them, /templates, /files and /badge/… for access badges. The full list of operations, with every field, is the API reference.

Authentication#

Send an API key in the X-API-Key header on every request. Keys are created in SettingsAPI keys, and each one carries a set of scopes that limits what it can do. See Authentication.

Shell

curl https://api.walletap.com/templates \
  -H "X-API-Key: $WALLETAP_API_KEY"

Requests and responses#

Request bodies are JSON, sent with Content-Type: application/json. The one exception is uploading an image, which can also be multipart/form-data.
Responses are JSON. Deleting a template or a file answers 204 with no body.
IDs are strings. Keep them exactly as returned.
Timestamps in responses — created, updated, expiresAt — are Unix epoch milliseconds.
Dates you send, such as a pass's validUntil, are ISO 8601. A bare date like 2026-12-31 is read as midnight UTC at the start of that day, so give an expiry its time, such as 2026-12-31T23:59:59Z.
Template objects use camelCase field names. File objects use snake_case (mime_type, template_id).

Pagination#

Lists come back in pages, in one of two styles:

Endpoint	Page size	Next page
`GET /templates`	`limit`, 15 by default, 100 at most	Pass `next_cursor` as `starting_after` while `has_more` is `true`
`GET /passes`	`limit`	Pass the `created` value of the last pass as `startAfter`

Versioning#

The API is versioned by date. The current version is 2026-05-13. Send it in the Walletap-Version header to pin your integration to it; the template and file endpoints echo the version they used back in the same response header.

Shell

curl https://api.walletap.com/templates \
  -H "X-API-Key: $WALLETAP_API_KEY" \
  -H "Walletap-Version: 2026-05-13"

Errors#

A failed request answers with a 4xx or 5xx status and a JSON body whose error field says what went wrong in plain words. Some errors add a machine-readable code, such as upgrade_required or insufficient_scope. See Errors for every status and code.

What happens on its own#

Some requests do more than change a record, and it is worth knowing before you script them:

Issuing a pass delivers it. POST /pass emails the pass link to the address you send, and texts it to the phone number, unless delivery is turned off in the request or in the account's delivery settings. See Issue passes.
Updating a pass updates the wallet. A change made with PATCH /pass is pushed to the phones holding that pass within moments.
Saving a template updates the passes issued from it. After PATCH /templates/{id}, passes in Apple Wallet refresh with the new design. In Google Wallet, template-wide parts change straight away, and each pass's own parts, such as its colour and back fields, change the next time that pass is updated.

To find out whether someone has added their pass to a wallet, read its deviceCount: it is the number of wallets holding the pass right now.

Next steps#

Issue your first pass

From API key to a pass on a phone, with curl.

Authentication

Create, scope, rotate and turn off API keys.

Work with passes

Read, update, stamp, notify and void passes.

API reference

Every endpoint and field.