Google Cloud Spanner API

Name: Cloud Spanner API
Brand: Cloud Spanner API
Availability: InStock

✓ Official Vendor SpecStorageDatabaseoauth250 EndpointsREST

For Agents

Run SQL queries and DML against globally distributed Cloud Spanner databases, manage schemas and instances, and orchestrate backups and restores. Sessions and transactions are first-class.

Install Jentic One Beta

Connect the Cloud Spanner API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Cloud Spanner API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Cloud Spanner API.

Provision Spanner instances and databases with chosen node counts and configurations

Apply DDL changes to evolve a database schema online

Open sessions, run SQL or partitioned reads, and commit or rollback transactions

GET STARTED

Start building with Cloud Spanner API

Explore with Jentic

View OpenAPI Document

Use Cases

Patterns agents use Cloud Spanner API for, with concrete tasks.

★ Provision Spanner for a New Service

When a team launches a new globally distributed service, automation creates a Spanner instance, then a database with an initial DDL script defining tables and indexes. The Cloud Spanner API exposes instance creation as a long-running operation and database creation with extraStatements for first-pass schema, so a service can be storage-ready in minutes.

POST /v1/{+parent}/instances with config 'regional-us-central1' and nodeCount=3, then POST /v1/{+parent}/databases with createStatement and the initial DDL extraStatements.

Read-Only Analytics Query

Issue a read-only SQL query against a Spanner database from a reporting agent. The flow opens a session, executes the SQL with single-use bounded staleness for cheaper reads, and returns rows. Cloud Spanner's strong consistency makes this safe for cross-region analytics.

POST /v1/{+database}/sessions to open a session, POST sessions/{session}:executeSql with sql='SELECT name, count FROM Metrics WHERE day=@d' and a 60-second staleness.

Scheduled Backup and Restore Drill

Run a nightly backup of a production Spanner database and periodically test the restore path into a staging instance. The API supports POST /v1/{+parent}/backups for take, GET listing, and POST /v1/{+parent}/databases:restore for the restore path. Each is a long-running operation trackable via the operations endpoint.

Create a backup of database prod-db with expireTime=now+30d, then poll the returned operation until done; in staging, POST databases:restore with the backup name.

AI Agent Schema Evolution

An AI agent reviewing a feature request decides a new column is needed on a Spanner table. The agent searches Jentic for the DDL update operation, loads the schema, and submits an updateDdl request. Jentic returns a long-running operation handle so the agent can poll for completion before proceeding.

Search Jentic for 'apply DDL to a Spanner database', execute PATCH /v1/{+database}/ddl with statements=['ALTER TABLE Orders ADD COLUMN region STRING(2)'].

Key Endpoints

50 endpoints — the cloud spanner api exposes google's globally distributed, strongly consistent relational database as rest operations.

METHOD

PATH

DESCRIPTION

POST

/v1/{+database}/sessions

Create a session for executing reads and transactions

POST

/v1/{+database}/sessions:batchCreate

Create multiple sessions in one call

PATCH

/v1/{+database}/ddl

Apply DDL statements to evolve a database schema

GET

/v1/{+name}

Get an instance, database, backup, or operation by resource name

POST

/v1/{+name}:cancel

Cancel a long-running operation

POST

/v1/{+name}:move

Move a database between instance configurations

POST

/v1/{+name}:changequorum

Change the quorum configuration of a database

POST

/v1/{+database}/sessions

Create a session for executing reads and transactions

POST

/v1/{+database}/sessions:batchCreate

Create multiple sessions in one call

PATCH

/v1/{+database}/ddl

Apply DDL statements to evolve a database schema

GET

/v1/{+name}

Get an instance, database, backup, or operation by resource name

POST

/v1/{+name}:cancel

Cancel a long-running operation

Why Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Spanner service-account credentials are stored in the Jentic vault (MAXsystem) and exchanged for scoped, short-lived access tokens on each call. Long-lived JSON keys never enter the agent context.

Intent-based discovery

Agents search Jentic with intents like 'run a SQL query against a Spanner database' or 'back up a Spanner database', and Jentic returns the matching executeSql or backups.create operation with its request schema.

Time to first call

Direct Spanner integration: 2-3 days to wire OAuth, sessions, transaction lifecycle, and long-running operations. Through Jentic: under 1 hour to discover the operation, load the schema, and execute.

FAQs

Specific to using Cloud Spanner API through Jentic.

What authentication does the Cloud Spanner API use?

The Cloud Spanner API uses OAuth 2.0 with the cloud-platform or spanner.data scope. Through Jentic, OAuth credentials are stored in the Jentic vault (MAXsystem) and exchanged for short-lived access tokens, so service-account JSON keys never enter the agent context.

Can I run arbitrary SQL against a Spanner database with the API?

Yes. Open a session under POST /v1/{+database}/sessions, then call POST .../sessions/{session}:executeSql with the SQL string and any parameters. For DML, wrap the call in a transaction by including a transaction selector with begin or id fields.

What are the rate limits for the Cloud Spanner API?

Cloud Spanner enforces per-instance throughput limits scaled by node count rather than per-call quotas. There are also admin-API quotas (default ~5 requests per second for instance and database admin calls). Heavy DML or large reads should be chunked across sessions to fit within node throughput.

How do I take a Spanner backup through Jentic?

Search Jentic for 'back up a Cloud Spanner database', load the backups.create schema, then execute POST /v1/{+parent}/backups with the source database name and an expireTime. The response returns a long-running operation that Jentic surfaces so the agent can poll for completion.

Is the Cloud Spanner API free?

Cloud Spanner itself is billed per node hour and per GB of storage, with backup storage charged separately. The API surface has no per-call charge — costs come from the underlying instance running the queries.

Can I run a partitioned read for a large scan?

Yes. Call POST .../sessions/{session}:partitionRead or partitionQuery to get partition tokens, then issue parallel POST .../sessions/{session}:streamingRead calls — one per partition — to scan the table in parallel.

Google Cloud Spanner API

Connect the Cloud Spanner API to your agent

Capabilities

Start building with Cloud Spanner API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs