Skip to main content

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.

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

FieldDefaultUnmask with
calls.caller_phone, leads.phone***-***-1234 (last 4 only)— (always masked)
calls.transcript, calls.transcript_turnsnulltranscripts:read
calls.recording_url, calls.public_log_urlnullrecordings:read
customers.email, leads.emailm***@premierhvac.com— (always masked)
bookings.customer_phone***-***-1234— (always masked)
location_members.emailj***@company.com— (always masked)
location_members.phone***-***-1234— (always masked)
subscriptions.stripe_customer_idomitted— (never exposed)
subscriptions.stripe_subscription_idomitted— (never exposed)
api_keys.* secret hashomitted— (never exposed)
integrations.access_tokenomitted— (never exposed)
integrations.refresh_tokenomitted— (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: 
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