Data Usage

1. Processing principles

• User-level access: no meeting-provider administrator scopes are requested.
• Purpose limitation: data is used only for the meeting workflow selected by the user.
• Tenant isolation: every API operation is bound to the authenticated user and connection.
• Minimal disclosure: private host links and management credentials are never posted into shared chats.
• No sale or advertising: provider data is not sold, profiled for ads or used to build advertising audiences.

2. User identity

Data accessed

Provider user ID, account ID, display name and email when available.

Purpose

To bind the OAuth grant to the correct application user, prevent one provider identity from being attached to multiple tenants, route signed events to the correct owner, and provide support.

Storage

Identifiers and available profile fields are stored with the connection. OAuth credentials are encrypted at rest.

3. Meetings

Data accessed

Meeting ID, UUID, title, type, schedule, duration, host identity, join URL and private start URL.

Purpose

• List the authenticated user's existing scheduled meetings.
• Create a new meeting when explicitly requested.
• Read or update a meeting before it is published.
• Start or delete a meeting only after an explicit user action.
• Resolve recurring meeting instances so that reports are associated with the correct occurrence.

Disclosure

The shared card contains the title, schedule and participant join link. The private start URL is returned only to the authenticated host after publication.

4. Recordings, transcripts and summaries

Data accessed

Cloud recording metadata and files, audio, participant audio, chat, captions, transcripts, provider-generated summaries, timeline data and past meeting instance details.

Purpose

To preserve requested meeting assets, obtain or create a transcript, generate a concise report, and deliver that report to the conversation selected by the user.

AI and transcription

Audio or transcript content may be sent to configured transcription and AI processing providers solely to produce the requested transcript or summary. It is not used by Zoombot for advertising or unrelated profiling.

5. Bitrix24 and Telegram data

Zoombot processes user, installation, chat, message and inline-result identifiers needed to publish a meeting card and update that exact card with a result. It does not read unrelated conversation history. Bitrix24 OAuth tokens are encrypted at rest; browser sessions are short-lived and bound to the verified user, installation, dialog and application placement.

6. Storage and protection

• OAuth tokens: AES-256-GCM encrypted storage.
• Application database: user and connection ownership constraints on meetings, jobs, reports and delivery targets.
• Local meeting assets: isolated directories keyed by application user and provider connection.
• Report links: high-entropy capability URLs without management credentials.
• Webhook payloads: signature verification and redaction of unknown or quarantined events.

7. Retention and deletion

Provider data remains while needed to provide the user's connected archive. A user can disconnect at any time or request deletion through Support. A valid provider deauthorization event deletes the exact connection's credentials, provider records and local archive.

When configured to clear cloud recordings, Zoombot first verifies the local copy, size and transcript requirements. Deletion is then performed through the provider API and recorded in an audit trail.

8. Questions