OAuth permissions
The private-beta Make OAuth client requests these eight baseline scopes for the guided modules:
The registered client also permits five optional advanced scopes. They are
not granted silently: the person creating the Make connection must explicitly
request the required advanced scope and approve it on Perkstar’s consent screen.
Granting all 13 allowed scopes is not required for ordinary guided scenarios.
Choose only the optional access required by the documented universal call. To
add an advanced scope later, update or replace the Make connection and approve
the expanded consent before running the scenario; an existing token does not
gain it automatically.
The connection cannot inspect or mutate webhook endpoints owned by another
OAuth application or user. Perkstar enforces tenant, plan, account state,
consent, card type, input validation, idempotency, and rate limits again when a
module runs.
Make an API Call uses the exact scopes granted to that connection: the eight
baseline scopes plus only the optional scopes the user selected. The module
does not grant every allowed scope merely because the OAuth client permits it,
and it cannot call private dashboard routes or switch businesses.
Data the app can process
Perkstar does not enrich every event with customer email, name, or phone merely
to make mapping convenient. Use a search only when current profile data is
necessary and authorised. The exact event fields are in the webhook event
catalogue.
Where Make can retain data
Depending on the scenario, workspace settings, plan, and connected apps, customer data can appear in:- scenario module inputs and output bundles;
- execution history and incomplete executions;
- webhook queues;
- Make Data Stores, variables, aggregators, and error handlers;
- copied blueprints, screenshots, or support exports; and
- every destination app and its own logs, backups, and retention.
Responsibility model
The business determines its legal role and purpose for each destination, limits who can edit scenarios or inspect executions, gives required notices, and handles access, correction, deletion, objection, and consent rights across all copies. Perkstar cannot govern a module after data enters Make.Consent and messaging
- Loyalty enrolment is not automatic email, SMS, advertising, profiling, or Wallet push-marketing consent.
- Treat Perkstar consent fields as purpose-specific state, not blanket permission for every scenario destination.
- Retain the source, wording, time, and lawful basis needed to support any consent assertion written from another application.
- Send a Wallet push enforces push-marketing consent. A
403is a safety outcome, not an error to route around. - Never place passwords, payment-card data, health data, or other sensitive free text in a loyalty note, push, Make variable, Data Store, or support request.
Minimise and protect
- Map only fields the next module needs.
- Prefer opaque Perkstar IDs to copying a full customer profile.
- Keep production connections and scenarios in the intended Make team; grant edit and execution-history access only to authorised members.
- Keep the private Make webhook URL, OAuth tokens, Wallet install links, and customer payloads out of logs, screenshots, blueprints, and tickets.
- Use separate test and live source-reference namespaces.
- Review routers and error handlers: a failed privacy/consent filter must not fall through to a sending route.
- Protect Data Stores and destination records with retention/deletion rules, not indefinite defaults.
Webhook authentication boundary
Perkstar signs outbound webhooks with HMAC-SHA256. Because Make exposes parsed JSON rather than the exact signed bytes, the official instant module performs an authenticated server-attestation request before emitting a bundle. Perkstar binds the proof to the app-owned webhook, OAuth application and user, organisation, delivery ID, signing time, signature, and event envelope. The signing secret remains encrypted in Perkstar and is not copied into Make. Keep the unique Make callback URL secret as an additional control. A failed or incomplete attestation must be investigated; do not route around it or map the unverified receiver payload directly. See Webhooks and instant scenarios.Disconnect, deletion, and rights requests
Deleting an attached Make webhook removes its corresponding app-managed Perkstar subscription. Revoking the connection stops future authorised API calls. Neither action automatically deletes:- Make execution history, incomplete executions, or queued/processed bundles;
- Make Data Store entries or copied scenario/blueprint data;
- records created in a CRM, spreadsheet, chat tool, or another destination; or
- Perkstar source records the business is otherwise entitled or required to retain.
Production review
- Beta access, scenario owner, Make team, Perkstar tenant, and destinations are documented.
- The OAuth connection uses the correct business and no raw API key exists in a module or variable.
- The scenario maps the minimum necessary fields.
- Consent and suppression behaviour is tested.
- Editors, connection users, execution viewers, and Data Store access are restricted.
- Stable references make customer and transaction writes retry-safe.
- Webhook URL secrecy and server-attested delivery rejection are tested.
- Revocation, attached-webhook deletion, queue handling, destination deletion, and rights requests are tested.