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.
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.Consent and messaging
- 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
403is 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
- Map only fields the next step needs.
- Use opaque Perkstar IDs instead of copying a full profile where possible.
- Limit who can edit the Zap and view Zap history.
- Configure destination retention and logs; do not assume turning off the Zap deletes historical tasks.
- Avoid broad chat-channel messages containing contact details or feedback text.
- 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.
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.

