canonical: https://jentic.com/apis/googleapis.com/notebooks # Google Notebooks API The Notebooks API manages Vertex AI Workbench managed notebook instances on Google Cloud. It provisions, starts, stops, upgrades, resets, and diagnoses Jupyter-based development environments backed by Compute Engine VMs with pre-installed ML frameworks. Use it to spin up GPU/TPU-equipped notebook VMs for data scientists, restore from backup, rollback to prior states, and pull diagnostic bundles when an instance misbehaves. The spec exposes 23 endpoints across regional locations. ## For AI agents Provision and manage Vertex AI Workbench notebook instances - start, stop, upgrade, diagnose - across Google Cloud regions. ## Scope Does not run notebook code, train models, or store data - use for managed notebook instance lifecycle operations only. ## Capabilities - Provision notebook instances with specific machine types, accelerators, and disk sizes - Start, stop, and reset running notebook VMs to control compute spend - Upgrade instance system images and rollback to prior versions when upgrades fail - Restore notebook instance state from backups taken on a defined schedule - Diagnose unhealthy instances and download diagnostic bundles for support cases - Audit instance configuration via instances:getConfig before applying changes ## Use cases ### Self-service data science environments Provision Vertex AI Workbench notebook instances for individual data scientists with consistent ML framework images, machine types, and accelerator attachments. The API gives platform teams a programmatic surface to enforce standards - VPC, service account, encryption key - while giving users on-demand compute. Pairs naturally with policy-as-code so each new instance is created from a vetted template. Example prompt: Create a notebook instance named ds-anna-gpu in us-central1-a with machine type n1-standard-8, one Tesla T4 accelerator, and a 200 GB boot disk. ### Cost control through automated start/stop Schedule notebook instance start and stop operations to reduce compute bills outside working hours. The API exposes :start, :stop, and :reset operations that fit cleanly inside Cloud Scheduler or a workflow runner. Combined with diagnostic downloads, this is enough to operate a hands-off notebook fleet for a data team. Example prompt: List all notebook instances in europe-west1, filter to those whose state is ACTIVE, and POST :stop on each instance whose name ends with -dev. ### Notebook image upgrades and rollback Upgrade notebook instances to newer framework images for security patches and library updates, with the safety net of :rollback when an upgrade breaks user workflows. The API records upgrade history so an agent can detect a recent upgrade and revert it without manual intervention. Useful for platform teams that maintain a managed notebook offering. Example prompt: Trigger upgrade on notebook instance ds-anna-gpu, poll the long-running operation, and execute :rollback if a follow-up health check returns FAILED. ### AI agent operations on notebook fleets via Jentic Operations agents can use Jentic to diagnose and remediate failing notebook instances - issuing intents like diagnose stuck notebook or restore from backup - and Jentic returns the matching Notebooks API operation. Credentials stay in your Jentic One instance, so agents act under scoped service-account tokens with full audit trail. Example prompt: Use Jentic to find the diagnose operation for a notebook instance, load its schema, and execute it on instance ds-anna-gpu, then download the resulting diagnostic bundle. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | POST | /v2/{+parent}/instances | Create a notebook instance | | POST | /v2/{+name}:start | Start a stopped instance | | POST | /v2/{+name}:stop | Stop a running instance | | POST | /v2/{+name}:upgradeSystem | Upgrade the system image | | POST | /v2/{+name}:rollback | Rollback to a prior revision | | POST | /v2/{+name}:diagnose | Generate a diagnostic bundle | | POST | /v2/{+name}:restore | Restore an instance from backup | ## Key resources - **instances** — Vertex AI Workbench managed notebook instances - **operations** — Long-running operations for instance lifecycle actions - **locations** — Regional location metadata for notebook capacity ## Why Jentic - **Setup:** Wiring the Notebooks API by hand means setting up Google OAuth 2.0 from a service account, minting scoped tokens, and polling the long-running instance lifecycle operations against notebooks.googleapis.com yourself. Through Jentic you install once, import the Notebooks API from the API Directory, store the OAuth credential once, and your agent calls it. - **Permission scoping:** The Notebooks API puts the instance in the URL path (/v1/{+name}:start, /v1/{+name}:stop), so a rule can pin your agent to one notebook instance: it can start, stop, and diagnose that instance and nothing else. You choose the operations it may call, so disruptive ones like rollback or restore are not included unless you add them. - **Credential handling:** Your Google OAuth credential for the Notebooks API is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'provision a GPU notebook' or 'diagnose a stuck instance', and Jentic returns the matching Notebooks API operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **Vertex AI API** — Vertex AI runs the training and inference jobs that notebooks orchestrate - **Compute Engine API** — Compute Engine offers raw VMs as an alternative to managed notebook instances - **BigQuery API** — BigQuery is the most common data source queried from Vertex notebooks ## FAQ ### What authentication does the Notebooks API use? The API uses Google OAuth 2.0 with the cloud-platform scope. Jentic mints scoped, short-lived tokens from a service account stored in its vault so agents never see raw credentials. ### Can I attach a GPU to a notebook instance through this API? Yes. Set acceleratorConfig in the instance body when calling POST /v2/{+parent}/instances; supported accelerator types follow Compute Engine's GPU SKU list for the chosen zone. ### What are the rate limits for the Notebooks API? Google Cloud enforces per-project quotas on instance create/update operations. Treat lifecycle changes as long-running - the API returns an operation, not a synchronous result, so back-off polling beats retry storms. ### How do I diagnose a stuck notebook through Jentic? Search Jentic for diagnose notebook instance, load the schema for POST /v2/{+name}:diagnose, and execute it with the diagnostic config. The returned operation eventually contains a GCS path to the diagnostic bundle. ### Does this API run notebook code itself? No - the API is a control plane for instance lifecycle. The actual Jupyter kernel runs inside the Compute Engine VM that backs the notebook instance and is reached via JupyterLab over a tunnelled HTTPS connection. ### How do I rollback after a failed upgrade? POST to /v2/{+name}:rollback with the targetSnapshot or revisionId from the prior version, then poll the returned operation until done is true. ### Can I limit what my agent is allowed to do with the Notebooks API? Yes. Because you self-host Jentic One, your own rules decide which Notebooks API operations and credentials the agent may use. Since the instance name sits in the URL path (for example /v2/{+name}:start and /v2/{+name}:stop), you can pin an agent to a single notebook instance and grant it only start, stop, and diagnose calls. Disruptive operations such as :rollback and :restore stay unavailable unless you explicitly add them to the agent's allowed set.