Skip to main content
Connecting Zapier creates a new data flow chosen by the Perkstar business. The business decides which Zap runs, which fields are mapped, which destination apps receive them, and how long those destinations retain them.
This page explains product behaviour and implementation responsibilities. It is not legal advice and does not replace the Perkstar Privacy Notice, Data Processing Agreement, Terms of Service, Zapier’s terms, or the business’s own privacy review.

Connection security

OAuth, not copied keys

Users approve Perkstar’s hosted OAuth flow. The official connection never asks them to paste a Perkstar API key into a Zap field.

One business per grant

Every credential resolves to one Perkstar organisation, and API resources are checked against that tenant boundary.

Scoped access

The consent screen describes the access used by the configured triggers, actions, searches, and card selector. Perkstar still enforces every scope.

Revocable

The connection can be revoked. Revocation stops future API access but does not erase Zap history or copies already sent to another app.
The prepared OAuth grant uses Authorization Code flow with required S256 PKCE, one-hour access tokens, and single-use rotating refresh tokens. Perkstar revokes the grant if an already-rotated refresh token is replayed. Each instant trigger also receives a per-subscription signing secret; the official app verifies the exact callback bytes and a five-minute HMAC timestamp before returning a Zap record.

Requested access

The Zapier OAuth application cannot use these permissions to inspect or mutate webhook endpoints created by a different OAuth application or user. Perkstar also enforces tenant, plan, account-state, consent, card-type, and rate-limit checks after the scope check.

Data the app can process

The exact fields for each event are in the webhook event catalogue. Perkstar does not add customer email, name, or phone to every trigger merely to make mapping convenient. Use a search only when the workflow needs current profile data and is authorised to copy it.

Responsibility model

The business is responsible for determining its role and lawful purpose for each destination, configuring access, giving required notices, and honouring access, correction, deletion, objection, and consent rights across all copies. Perkstar cannot govern a later Zap step after the data leaves Perkstar.
  • A loyalty enrolment does not automatically grant email, SMS, advertising, or push-marketing consent.
  • Treat Perkstar consent fields as purpose-specific state, not blanket permission for every Zap destination.
  • Keep the source, wording, time, and lawful basis needed to support any consent assertion written from another app.
  • Send Wallet Push enforces push-marketing consent. A 403 is a safety outcome, not an error to route around.
  • Never place payment-card data, passwords, health data, or other sensitive free text in a loyalty note, push message, Zap field, or support request.

Minimise and retain deliberately

  1. Map only fields the next step needs.
  2. Use opaque Perkstar IDs instead of copying a full profile where possible.
  3. Limit who can edit the Zap and view Zap history.
  4. Configure destination retention and logs; do not assume turning off the Zap deletes historical tasks.
  5. Avoid broad chat-channel messages containing contact details or feedback text.
  6. Redact customer payloads, OAuth tokens, unique hook target URLs, and Wallet URLs from screenshots and support messages.

Disconnect, deletion, and rights requests

Turning off a Zap stops future runs and deletes its corresponding app-managed Perkstar instant-trigger subscription. Re-enabling the trigger creates a fresh subscription and secret. Revoking the connected account stops future authorised API calls and pauses its remaining owned subscriptions. None of those actions automatically delete:
  • completed Zap runs in Zap history;
  • records created in a CRM, spreadsheet, chat tool, or other destination;
  • source records that another app still controls; or
  • Perkstar records the business is otherwise entitled or required to retain.
For a rights request, locate data by Perkstar ID and any stable external reference, then apply the required export, correction, suppression, or deletion in Perkstar, Zapier, and each destination. Test this process before a live Zap copies customer data.

Operational review

  • The Zap owner, every connected app, and every person who can edit the Zap are documented.
  • The Zap uses the correct tenant and minimum necessary fields.
  • Consent and suppression behavior is tested.
  • Zap editors and Zap history viewers are restricted.
  • Stable references make customer and transaction writes retry-safe.
  • Revocation, trigger removal, and destination deletion are tested.
  • Rights requests and incidents have named owners.
Report suspected credential exposure, unauthorised access, or a personal-data incident to privacy@perkstar.co.uk. For an operational failure, follow Zapier troubleshooting.