> ## Documentation Index
> Fetch the complete documentation index at: https://developers.perkstar.co.uk/llms.txt
> Use this file to discover all available pages before exploring further.

# Make data and security

> Understand OAuth scopes, personal-data flow, consent, Make retention surfaces, and shared responsibilities.

Perkstar for Make uses OAuth with tenant-scoped access. The person connecting
the app approves one Perkstar business; the resulting Make connection cannot
read or write another business. Do not share a raw Perkstar API key with a
scenario builder, contractor, or destination app.

## OAuth permissions

The private-beta Make OAuth client requests these eight baseline scopes for the
guided modules:

| Scope              | Why the app needs it                                                                               |
| ------------------ | -------------------------------------------------------------------------------------------------- |
| `CUSTOMERS_READ`   | Find customers and return current customer fields needed by searches and guided workflows.         |
| `CUSTOMERS_WRITE`  | Create or update customers through the explicit guided actions.                                    |
| `ENROLLMENTS_READ` | Find a customer/card relationship, balance, status, and available Wallet links.                    |
| `CARDS_READ`       | Populate dynamic Card selectors and validate card-aware modules.                                   |
| `EVENTS_READ`      | Read bounded recent event samples where the trigger setup requires them.                           |
| `WEBHOOKS_WRITE`   | Create/delete app-owned subscriptions and attest signed deliveries behind attached Make webhooks.  |
| `MARKETPLACE`      | Enrol customers, record supported loyalty activity, and reverse eligible marketplace transactions. |
| `PUSHES_WRITE`     | Send one consent-checked Wallet push through the explicit action.                                  |

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.

| Optional scope       | Advanced public API use                                                     |
| -------------------- | --------------------------------------------------------------------------- |
| `ENROLLMENTS_WRITE`  | Call a documented public enrolment mutation without a guided module.        |
| `TRANSACTIONS_READ`  | Read a supported transaction resource through **Make an API Call**.         |
| `TRANSACTIONS_WRITE` | Call a supported direct transaction write after designing retry protection. |
| `WEBHOOKS_READ`      | Read supported app-owned webhook resources through the public API.          |
| `LOCATIONS_READ`     | Read the connected business's supported location resources.                 |

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

| Feature                     | Potential Perkstar data                                                                                                                         | Why it is used                                                                                    |
| --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| Watch loyalty events        | Event ID/type/time, organisation ID, and event-specific customer, card, enrolment, loyalty, purchase, membership, engagement, or booking fields | Start the selected scenario and expose mapping fields.                                            |
| Search customers            | Customer ID/number, contact/profile fields, consent flags, external reference, and lifecycle timestamps                                         | Return current customers matching optional exact contact/reference/pass filters or Created after. |
| Search enrolments or passes | Customer/Card IDs, status, balance/activity values, and available Wallet install URLs                                                           | Return current programme relationships matching optional Customer ID, Card, and Status filters.   |
| Customer actions            | Identity, profile, consent, and external-reference fields explicitly mapped by the builder                                                      | Create or update the intended customer.                                                           |
| Loyalty actions             | Customer lookup, Card, amount/delta, stable source reference, note, and selected metadata                                                       | Enrol, record one compatible activity, redeem, or reverse the original transaction.               |
| Wallet push                 | Enrolment, message, resolved merge fields, source event ID, and delivery result                                                                 | Send one business-authored message to eligible Wallet passes.                                     |
| Make an API Call            | Request and response fields of the selected supported public v1 operation                                                                       | Cover a documented operation without a guided module.                                             |

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](/reference/webhook-events).

## 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.

Turning a scenario off or revoking OAuth stops future work but does not
automatically erase those copies. Configure access and retention in Make and
every destination according to the business's policy; do not rely on Perkstar
to delete records after they leave its platform.

## Responsibility model

```mermaid theme={null}
flowchart LR
  Customer["Cardholder"] --> Business["Business using Perkstar\nNormally the controller"]
  Business --> Perkstar["Perkstar\nNormally a processor"]
  Business --> Make["Make organisation and connected apps\nChosen by the business"]
  Perkstar --> Make
  Make --> Destination["Scenario destinations"]
```

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 `403` is 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

1. Map only fields the next module needs.
2. Prefer opaque Perkstar IDs to copying a full customer profile.
3. Keep production connections and scenarios in the intended Make team; grant
   edit and execution-history access only to authorised members.
4. Keep the private Make webhook URL, OAuth tokens, Wallet install links, and
   customer payloads out of logs, screenshots, blueprints, and tickets.
5. Use separate test and live source-reference namespaces.
6. Review routers and error handlers: a failed privacy/consent filter must not
   fall through to a sending route.
7. 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](/integrations/make/webhooks).

## 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.

For a rights request, locate data by Perkstar ID and stable external reference,
then perform the required export, correction, suppression, or deletion in
Perkstar, Make, and every destination. Test this procedure before a live
scenario distributes personal data.

## 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.

Report suspected credential exposure, unauthorised access, or a personal-data
incident to [privacy@perkstar.co.uk](mailto:privacy@perkstar.co.uk). For an
operational failure, follow [Make troubleshooting](/integrations/make/troubleshooting).


## Related topics

- [Zapier data and security](/integrations/zapier/data-security.md)
- [Security, privacy, and data handling](/fundamentals/security-privacy.md)
- [Make](/integrations/make/index.md)
- [Connect Perkstar to Make](/integrations/make/setup.md)
- [Webhooks and instant scenarios](/integrations/make/webhooks.md)