Skip to main content
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

​
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:
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