Integration

Google Drive, and the files that belong to the wrong person

A Google Drive integration files documents collected through a Telegram bot into the folder structure your team already uses. The trap is ownership: files a service account creates in My Drive belong to the service account, count against its quota, and are invisible to everyone else.

Google Drive integration: auth, limits and availability

Auth model: OAuth 2.0
Ownership trap: Service-account files in My Drive count against the service account quota
GCC availability: Shared drives require Workspace; personal accounts hit ownership limits
Data flow: 5 hops, worker-mediated

As of 2025-10-01, Telegram Bot API 13.4

Why this integration exists

Document collection through a bot only pays off if the files land where people already look. A perfectly organised archive in a system nobody opens is a slower version of asking by email, so the integration is judged on whether the matter folder a paralegal opens on Monday contains what the client sent on Friday.

The failure that recurs is ownership, and it is specific to how Drive works. A service account uploading into My Drive owns the resulting files. It has its own small storage quota, so uploads start failing once it is full, and the files are invisible to your staff unless each one is explicitly shared. Everything appears to work during testing with a handful of documents and then degrades in a way that looks like an outage.

The answer is shared drives, where the drive owns the content rather than the uploader. The service account is added as a member, files inherit the drive's permissions, and storage counts against the organisation rather than a robot account. It is a five-minute configuration difference and it is the difference between an integration that works for a year and one that fails in month two.

How the data actually moves

A durable copy is written before the Drive upload, so a quota error or an outage delays filing rather than losing the client's document.

A service account added as a member of the target shared drive, with its key held as a Worker secret. Domain-wide delegation is available where files must be created as a specific user, though for document collection the shared drive approach is simpler and avoids impersonating anyone.

Auth model: OAuth 2.0

Their limits, and what they mean for you

Files created by a service account in My Drive are owned by it and count against its own quota.

Shared drives are used instead, where the drive owns the content. Otherwise uploads fail once the service account fills up and nobody can see the files meanwhile.

The Drive API applies per-project and per-user quotas measured per 100 seconds.

A batch of documents arriving together can trip the short window. Uploads are queued with backoff rather than issued as files arrive.

Uploads above roughly 5 MB should use the resumable protocol.

A scanned multi-page PDF frequently exceeds it. Simple uploads fail on flaky connections in a way resumable uploads recover from.

Folder names are not unique and files are addressed by id.

Folder ids are resolved once and stored. Locating a folder by name each time is both slower and wrong the moment two matters are named similarly.

How it fails, and what happens when it does

Uploads begin failing with a storage error weeks after launch.

The service account's own quota filled up because files went to My Drive. The shared drive arrangement removes the failure mode entirely rather than raising the ceiling.

Staff cannot see files the bot says it filed.

The same ownership problem seen from the other side. Files in a shared drive inherit its permissions and are visible without any per-file sharing step.

A folder is renamed or moved by a member of staff.

Stored folder ids survive both, which is the main argument for resolving by id rather than by path. A path-based integration breaks the first time somebody tidies up.

A large upload fails mid-transfer on a poor connection.

Resumable uploads continue rather than restart. Combined with the durable copy in R2, a failed transfer costs time rather than the document.

Availability in the UAE and the wider GCC

Google Workspace customers

The intended case. Shared drives require Workspace, and they are what makes this integration durable.

Personal Google accounts

No shared drives, so ownership and quota problems are unavoidable. Workable for a sole practitioner and fragile for a business.

Data residency

Files live in Google's infrastructure. Where a regulator requires local residency of client documents, that is a decision for counsel before selecting a store.

Retention obligations

Drive retention is configured in Workspace rather than by the bot. The bot files documents; deletion policy belongs to your administrators.

When not to use this integration

You have no Workspace and cannot use shared drives. Ownership and quota problems then have no clean solution.
Client documents must stay in-country. Residency is a decision for counsel rather than an integration setting.
Nobody has agreed the folder structure. The bot will file consistently into a structure nobody uses.
You need document management rather than storage. Drive stores files; it does not do versioned matter management.

What it runs on

Component	Version	Why
Cloudflare Workers	current	Service account auth, queued resumable uploads and folder resolution.
Cloudflare R2	current	Durable copy written before the Drive upload is attempted.
Cloudflare D1	current	Folder id cache, upload queue and filing state per matter.
Zod	4.4	Validation of API responses and upload results.

Questions that come up during scoping

Why do uploads start failing after a few weeks?

Almost always because files are going into My Drive, where the service account owns them and they count against its own small quota. Shared drives remove the failure mode rather than raising the ceiling, and it is a configuration difference rather than a code one.

Why can staff not see files the bot filed?

The same ownership problem from the other side. Files a service account creates in My Drive are visible only to it unless each one is shared explicitly; in a shared drive they inherit the drive's permissions automatically.

Should we resolve folders by name or by id?

By id, resolved once and stored. Folder names are not unique and staff rename and move things, so a path-based integration breaks the first time somebody tidies up — which is not a rare event.

What happens if a large scan fails to upload?

Resumable uploads continue rather than restart, and a durable copy was already written before the Drive attempt. A failed transfer costs time rather than the client's document.

Does the bot control retention?

No. Retention is configured in Workspace by your administrators. The bot files documents and records where they went; deletion policy is deliberately not something it decides.

Can this feed an AI assistant later?

Yes, and it is a common progression — the same shared drive becomes the corpus. Filing consistently from the start is what makes that possible without a retrospective cleanup project.