Data and privacy

Privacy notice

Effective November 1, 2026

Who and what this notice covers

Shawn Callback Booking is being prepared for Shawn’s personal callback scheduling. This notice describes the relay’s intended processing of caller information and the calendar owner’s Google data. It does not replace the privacy notices or retention policies of Bland, Cloudflare, Google or xAI/Grok.

Information the relay is designed to process

• Caller details: a name, confirmed callback phone number, brief memo, explicit preferred date, time and time zone, and confirmation of the scheduling request. An explicitly requested duration is checked against the fixed appointment length.
• Call and processing details: call identity, source agent and inbound-number identity, completion time, payload fingerprints, booking status, retry counts and error categories. Stored references are hashes or operational identifiers; they are not necessarily anonymous.
• Google Calendar data: configured calendar identifiers and free/busy intervals for the requested appointment window and buffer. The relay can fetch its identified event to confirm whether an attempted creation succeeded. That response can include the event description and Google event metadata, such as organizer details; the relay checks status, times and its identifying markers and does not keep unneeded response fields. It does not list all event descriptions or expose the other calendars’ contents to callers.
• Authorization credentials: the calendar owner’s dedicated OAuth client credentials and refresh token would be stored as Cloudflare Worker secrets, used to obtain short-lived Google access tokens. Callers do not supply Google credentials.

A Bland post-call payload may contain additional material, such as a transcript or recording link. The relay must receive and authenticate the payload before accepting its typed scheduling fields. It does not download recordings, infer appointments from arbitrary transcript text, or retain the raw transcript in its booking ledger. Its configured code does not log payloads or tokens. Bland’s own call processing and retention are separate.

Purpose and permissions

The intended purposes are to check the requested time, create a callback appointment, avoid duplicate processing, recover an uncertain creation result and inform Shawn of the outcome. A successful appointment would contain the caller’s name, number and memo in a private event description. Calendar visibility also depends on the owner’s Google sharing settings.

The dedicated Google connection is intended to request calendar.events.freebusy and calendar.events.owned, with offline access. The latter permission is broader than creation alone and technically permits reading, editing and deleting owned-calendar events. The relay implements only fixed availability checks, an identified-event read and a new-event insert in the configured Personal calendar. It does not invite attendees, create conference links, edit or delete events, or place calls.

Providers and intended sharing

• Bland: handles the inbound conversation and supplies the post-call webhook and extracted fields. Its call records, audio or transcripts are subject to its configuration and policies; this relay does not control their deletion.
• Cloudflare: hosts the disabled relay. Cloudflare also hosts this information site. Once the relay is activated, it would process authenticated webhook and Google responses, store the queue and operational records, and hold Worker secrets. Infrastructure processing may include network and security metadata.
• Google: would receive authorization requests, availability queries and new callback event contents, and store the resulting calendar entries in the owner’s account.
• xAI/Grok, through Rob: would receive only a result reference, booking outcome/reason and, for a booked appointment, its start/end and time zone for an owner notification. The relay does not send Rob caller names, numbers, memos, transcripts, calendar/event links, or unrelated busy intervals. Rob’s notification-only restrictions and provider settings have not yet been verified.

Caller names, callback numbers, memos and requested scheduling details originate from Bland’s post-call data. Rob does not receive those text fields. Rob may receive Google-derived information in a confirmed booking result, appointment times, or an availability-based rejection, together with a pseudonymous processing reference. Minimizing the result does not make it anonymous or remove applicable Google-data restrictions.

The relay has no advertising, resale, credit-scoring or model-training feature. Before enabling the Google-derived notification flow, the operator must verify that the selected Grok service, account settings and terms support Google’s restrictions on use and transfer, including restrictions on generalized AI-model training. That verification is pending. Notifications remain disabled, and this notice makes no claim about unverified provider practices.

Shawn Callback Booking will use Google data only for the scheduling and owner-notification features described here, in accordance with the Google API Services User Data Policy, including its Limited Use requirements. This is our operating policy; it does not mean that Google has verified the application.

Retention and deletion

• Caller details in the relay: name, phone number, memo and requested local date/time/zone are removed when a job is finalized, or at 30 elapsed days after receipt. An expiry alarm is scheduled even when another job blocks booking. Provider outages or quota limits can delay the alarm’s physical deletion work; expired jobs cannot create new appointments.
• Operational records: completed records are compacted after 30 days when notifications and reservations no longer need them. Call/payload hashes, event ID, status and operational timestamps/counters can remain for at least 90 days to prevent duplicates. A future reservation retains its interval through event end plus the 15-minute buffer. An unresolved write may retain minimal calendar/event/time recovery information until reviewed, without retaining caller fields beyond their expiry rule. A nonpersonal replay cutoff remains after old rows are removed.
• Google Calendar entries: created events, including caller details in their descriptions, remain in Google Calendar until the owner removes them under Google’s controls. Purging relay data does not remove those events.
• Provider copies: Bland call records, Grok conversations/results, Cloudflare backup snapshots and other provider records follow the relevant provider’s policies and settings. Relay expiry does not promise their deletion.

Protection and practical limits

The implemented relay checks webhook signatures, permits only configured sources and calendar destinations, bounds caller fields, keeps credentials out of payload logs, and uses HTTPS for provider requests. The design stores deployment credentials using a local keychain-backed mechanism and runtime credentials in Cloudflare secrets. These controls reduce exposure but do not guarantee that a service is secure or always available.

Missing details, unavailable calendars and uncertain writes stop new booking work. An appointment can still conflict with a change made independently in Google Calendar between the availability check and creation. A notification accepted by Grok is not proof it was delivered or read.

Your controls and requests

The calendar owner can revoke the dedicated application’s Google access using Google Account controls. Revocation stops future authorized access; it does not delete existing events, relay records or provider copies. The owner can remove calendar entries directly in Google Calendar. The relay does not provide a public deletion or account-management interface.

Contact: for privacy questions or correction/deletion requests concerning Shawn Callback Booking, email hsiangkunshih@gmail.com. Requests may require enough information to locate the relevant record; provider records may need to be handled through that provider.

This information site

These information pages contain no forms, trackers, analytics scripts or embedded third-party content. Cloudflare hosts the pages and may process ordinary request metadata such as IP addresses and browser headers under its own policies. The pages do not authorize Google access or submit callback requests.

Changes

We will update this notice when the service’s data handling changes and show the revised effective date here. Material changes to Google-data use will be disclosed before that new use begins.