> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pickupbell.com/llms.txt
> Use this file to discover all available pages before exploring further.

# PII scrubbing

> What gets redacted when you read via API key, and how to unmask it.

Bearer-token requests — REST or MCP — get redacted data by default. Scrubbing happens inside the service layer, so REST and MCP behave the same way.

## What's scrubbed by default

| Field                                         | Default                      | Unmask with        |
| --------------------------------------------- | ---------------------------- | ------------------ |
| `calls.caller_phone`, `leads.phone`           | `***-***-1234` (last 4 only) | — (always masked)  |
| `calls.transcript`, `calls.transcript_turns`  | `null`                       | `transcripts:read` |
| `calls.recording_url`, `calls.public_log_url` | `null`                       | `recordings:read`  |
| `customers.email`, `leads.email`              | `m***@premierhvac.com`       | — (always masked)  |
| `bookings.customer_phone`                     | `***-***-1234`               | — (always masked)  |
| `location_members.email`                      | `j***@company.com`           | — (always masked)  |
| `location_members.phone`                      | `***-***-1234`               | — (always masked)  |
| `subscriptions.stripe_customer_id`            | omitted                      | — (never exposed)  |
| `subscriptions.stripe_subscription_id`        | omitted                      | — (never exposed)  |
| `api_keys.*` secret hash                      | omitted                      | — (never exposed)  |
| `integrations.access_token`                   | omitted                      | — (never exposed)  |
| `integrations.refresh_token`                  | omitted                      | — (never exposed)  |

## Why phone numbers are never unmaskable via API

Callers are third parties who haven't consented to their number being shared with every Zapier integration a contractor sets up. You still have enough to:

* match a caller to a known customer in your CRM (the last-4 digits + time-of-call are enough to disambiguate in nearly all cases)
* compute metrics (caller is returning? first-time? urgency?)

If you have a compelling use case for full phone numbers over API, email support.

## Unmasking transcripts and recordings

Add the relevant scopes when you create the key:

```bash theme={null}
curl -X POST https://api.pickupbell.com/api/v1/locations/premier-hvac/api-keys \
  -H "Authorization: Bearer 550e8400-e29b-41d4-a716-446655440000" \
  -d '{
    "label": "reporting pipeline",
    "scopes": ["calls:read", "transcripts:read", "insights:read"]
  }'
```

Without `transcripts:read`, calling `GET /calls/:id` returns the row but with `transcript: null`. With it, the full text is present. Same pattern for `recordings:read`.

## Sensitive-data sinks

Because transcripts can contain PII the caller volunteered (addresses, spoken credit card numbers if the AI slipped — though it shouldn't per compliance settings), please:

* **log sparingly** — don't dump whole transcripts into CloudWatch
* **scope aggressively** — keep the transcript-capable key on a separate integration from general BI
* **rotate more often** — a few-month cadence is reasonable for `transcripts:read` keys