Google Slides
Google Slides for fancy-flow — as four imported, versioned packages, one per runtime. Not vendored source: a copy cannot be upgraded, and third-party APIs change.
| Runtime | Package | Install |
|---|---|---|
| Authoring surface (every host) | @particle-academy/google-slides-ui |
npm install @particle-academy/google-slides-ui |
| Node | @particle-academy/google-slides-js |
npm install @particle-academy/google-slides-js |
| PHP 8.4+ | particle-academy/google-slides-php |
composer require particle-academy/google-slides-php |
| Python 3.11+ | fancy-google-slides |
pip install fancy-google-slides |
The ui package is the editor surface and is React on every host — a PHP or
Python project installs it and its own runtime package, and never the js one.
What it costs you
One dependency: @particle-academy/fancy-connector-core (or
particle-academy/fancy-connector-core on Composer), which the js and php
packages pull in themselves. The Python package has zero runtime
dependencies.
No Google Slides SDK. Plain HTTP, deliberately: a vendor SDK is third-party code subject to the kit's full approval bar, and one per provider is hundreds of dependencies nobody is tracking.
Setting it up
Everything below is generated from provider/manifest.json, so it cannot disagree with what the packages do.
Credentials
A Google Slides connection holds 4 values.
Two kinds of value, and mixing them up matters. A provider credential is ONE value for the whole installation — an OAuth app's client secret serves every connected account. An account credential is one per connected account. A host that stores the second where it stores the first lets one account's credentials reach another's.
| Field | Scope | Secret | Where it comes from |
|---|---|---|---|
| OAuth client ID | per installation | not secret | From Google Cloud Console -> APIs & Services -> Credentials. ONE value for the whole installation, not per connected account. |
| OAuth client secret | per installation | secret | The client secret for the same OAuth app. One value for the whole installation. |
| Access token | per connected account | secret | Per connected Google account, and it expires after ONE HOUR. The host refreshes it with the refresh token. |
| Refresh token | per connected account | secret | Per connected Google account. Google issues one only when the consent request asks for offline access; without it the connection dies within the hour. |
Authorising
Google Slides uses OAuth2 (authorization_code). The package DECLARES the exchange; the HOST performs it — a consent screen needs a browser, a redirect URI and somewhere to persist the result, and all three belong to the host.
- Authorize URL — https://accounts.google.com/o/oauth2/v2/auth
- Token URL — https://oauth2.googleapis.com/token
- Scopes —
https://www.googleapis.com/auth/presentations - Access token lifetime — 3600 seconds (1 hours). A host that never refreshes works all afternoon and is broken by morning.
One consent grant, shared (grant: "google"). Every connector declaring the same grant can run on ONE OAuth client, with one consent and one refresh token per person.
- Authorize with
access_type=offline,include_granted_scopes=true. Ask for a feature's scopes when it is first used; the new token covers every scope granted before. A refresh token comes back only on the FIRST exchange, so keep the stored one when an exchange returns none. - Revoke — POST https://oauth2.googleapis.com/revoke with
token. It removes the WHOLE grant: every connector sharing it, not only this one. A per-feature disconnect stops using that feature's scopes locally; only a full disconnect revokes. - Identify the account by
sub: requestopenid, then verify the token response's id_token (issuerhttps://accounts.google.comoraccounts.google.com, keys at https://www.googleapis.com/oauth2/v3/certs, audience =clientId). Never key a connection by email. - No restricted scopes in this connector.
The refresh tokens do not rotate: the same one is reusable, so a refresh may safely be retried and may run concurrently. Stated rather than assumed, because the opposite — a provider that spends the token and revokes the grant on a replay — looks identical until it happens.
The estate
Google Slides has no test estate, and somebody checked. Everything this connector does is real. Use the faker to build against it.
Google has no sandbox for Slides. A test presentation is a real one in a real Drive, so every create is real -- use the faker while developing and clean up any live test presentations.
What it can do
Actions
presentation_create — Google Slides presentation
Create a blank Google Slides presentation.
POST /v1/presentations · unsafe to replay — a retried durable run does it TWICE
| Input | Required | What it is |
|---|---|---|
title |
yes | The title of the new blank presentation. |
presentation_get — Google Slides presentation
Read a presentation's slides and the objectId of every element on them -- the prerequisite for targeting a specific shape or placeholder with a future edit.
GET /v1/presentations/{presentationId} · reads only — safe to replay
| Input | Required | What it is |
|---|---|---|
presentationId |
yes | From presentation_create's data.presentationId, or the id in the presentation's own URL. |
Run it before you have credentials
Every operation ships a faker, whether or not Google Slides has a sandbox. Set a
node's mode to fake and it returns the shape Google Slides actually publishes — the
same field names, deterministically — so you can wire the downstream nodes before
touching an account, a key, or a network.
This repository is generated
provider/ is the source. Everything under packages/ is emitted from it and
must not be hand-edited — CI regenerates and diffs on every push, and the
next protocol sync destroys anything it finds. See AGENTS.md.
Two namespaces, which do not match on purpose
The repo is github.com/Fancy-Friends/google-slides; the packages publish under
particle-academy. Nothing derives one from the other — the names come from
weaver's friends.json and nowhere else.
Licence
MIT.
Metadata
Release files for fancy-google-slides 0.6.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| fancy_google_slides-0.6.0.tar.gz | 23.6 kB | Without provenance | Details for fancy_google_slides-0.6.0.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| fancy_google_slides-0.6.0-py3-none-any.whl | Python 3 | none | any | Details for fancy_google_slides-0.6.0-py3-none-any.whl |
Total release size: 46.3 kB
Release files / fancy_google_slides-0.6.0.tar.gz
| Download URL | fancy_google_slides-0.6.0.tar.gz |
|---|---|
| Size | 23.6 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
0669ddeb95255f5bec4f2ae11888841ef2e60b646d63e170e31436050efaf9ac
|
|
BLAKE2b-256 checksum How to use checksums |
354309ce712f777513f9b1bc059b6163811bb4c544fbf8a7c9539f7ba1abd2b8
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.13.18
|
Release files / fancy_google_slides-0.6.0-py3-none-any.whl
| Download URL | fancy_google_slides-0.6.0-py3-none-any.whl |
|---|---|
| Size | 22.7 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
f3cf6eab7dcda4004841e061a9d9111931a2a3a99c2244f1b2a8b57057fd5e87
|
|
BLAKE2b-256 checksum How to use checksums |
335ed4c487cdf28943dde379fac67b7a981f976f81ed9b06fb6230aabeab776e
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.13.18
|
Security for fancy-google-slides 0.6.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.