For Agents
Manage Google Cloud Pub/Sub Lite topics, subscriptions, reservations, and partition cursors for cost-efficient zonal streaming workloads.
Install Jentic One Beta
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Pub/Sub Lite 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 | shStep 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 instanceJentic 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.
What an agent can do with Pub/Sub Lite API.
Create and configure Pub/Sub Lite topics with explicit partition counts and per-partition throughput
Create subscriptions on a topic with delivery and backlog retention settings
Manage reservations to share throughput capacity across multiple topics
GET STARTED
Use for: I need to create a Pub/Sub Lite topic with 4 partitions, Inspect the consumer lag on a Pub/Sub Lite subscription, Create a reservation that shares throughput across multiple topics, Seek a subscription back to a specific publish timestamp
Not supported: Does not handle global multi-region messaging, push subscription delivery, or schema-validated topics — use for zonal partition-based streaming, capacity reservations, and cursor management only.
Google Cloud Pub/Sub Lite is a zonal, partition-based messaging service that offers lower per-message cost than Pub/Sub at the expense of zonal availability and explicit partition and capacity management. The admin API exposes topics, subscriptions, reservations, and partition statistics, while the cursor and topicStats APIs let consumers manage commit positions and inspect lag and throughput. Pub/Sub Lite is well suited for log ingestion, event archival, and telemetry pipelines that can tolerate zonal scope in exchange for predictable economics.
Inspect partition statistics, message backlog, and consumer lag for a topic
Commit cursor positions for subscriptions to track consumer progress
Seek subscriptions to a published time or starting offset for replay
Patterns agents use Pub/Sub Lite API for, with concrete tasks.
★ Cost-Efficient Log Ingestion
Pub/Sub Lite ingests application logs and telemetry at lower cost than Pub/Sub by trading global delivery for zonal partition-based throughput. Operators size partitions to expected throughput, attach subscriptions for downstream consumers, and use reservations to amortize capacity across topics.
Create a topic with 4 partitions and 4 MiB/s publish capacity per partition, then create a subscription named app-logs-archive for downstream archival.
Backlog Monitoring and Capacity Sizing
Operators monitor partition statistics and consumer lag to spot under-provisioned consumers and to decide when to scale partition counts. The topicStats and admin APIs expose backlog size and committed cursor positions per partition so dashboards can be built without polling consumers directly.
Compute backlog by partition for subscription telemetry-sub and alert when any partition has more than 60 seconds of unacked messages.
Replay and Reprocessing Pipelines
When a downstream consumer ships bad logic or a sink fails, operators rewind a Pub/Sub Lite subscription to a prior publish time and reprocess the affected window. The seek operation on the admin API issues this rewind without disturbing other subscriptions on the same topic.
Call seek on subscription orders-archive-sub with target publish_time set to one hour before the bad deploy to re-emit messages from that window.
Agent-Driven Streaming Operations
An ops agent uses Jentic to inspect Pub/Sub Lite lag, scale partitions, and trigger replays in response to alerts, so on-call engineers can resolve issues by describing intent rather than memorizing admin API paths.
Search Jentic for seek a pubsub lite subscription, load the schema for the admin seek operation, and execute it with the publish_time payload.
20 endpoints — google cloud pub/sub lite is a zonal, partition-based messaging service that offers lower per-message cost than pub/sub at the expense of zonal availability and explicit partition and capacity management.
METHOD
PATH
DESCRIPTION
/v1/admin/{+parent}/topics
List Pub/Sub Lite topics under a parent
/v1/admin/{+parent}/subscriptions
List subscriptions in a parent
/v1/admin/{+parent}/reservations
List reservations in a parent
/v1/admin/{+name}/partitions
Get partition information for a topic
/v1/admin/{+name}:seek
Seek a subscription to a publish time or offset
/v1/admin/{+name}:cancel
Cancel a long-running operation
/v1/admin/{+parent}/topics
List Pub/Sub Lite topics under a parent
/v1/admin/{+parent}/subscriptions
List subscriptions in a parent
/v1/admin/{+parent}/reservations
List reservations in a parent
/v1/admin/{+name}/partitions
Get partition information for a topic
/v1/admin/{+name}:seek
Seek a subscription to a publish time or offset
Three things that make agents converge on Jentic-routed access.
Credential isolation
Google OAuth 2.0 credentials are stored encrypted in the Jentic vault. Scoped, short-lived access tokens are issued per call so the OAuth client secret never enters the agent context, and IAM bindings on the project determine what admin and cursor operations the agent can perform.
Intent-based discovery
Agents search Jentic by intent (e.g., create a topic, seek a subscription, inspect lag) and Jentic returns the matching Pub/Sub Lite admin or topicStats operation with its input schema so the agent can build a correct request without parsing the discovery doc.
Time to first call
Direct integration takes 2-3 days because partition sizing, reservations, and cursor semantics need to be modelled correctly. Through Jentic: under 1 hour — search, load schema, execute.
Alternatives and complements available in the Jentic catalogue.
Specific to using Pub/Sub Lite API through Jentic.
What authentication does the Pub/Sub Lite API use?
The API uses Google OAuth 2.0 with the cloud-platform scope, sent as a Bearer token. Through Jentic the OAuth credentials live in the vault and short-lived access tokens are minted per call so the refresh token never enters the agent context.
How is Pub/Sub Lite different from Pub/Sub?
Pub/Sub Lite is zonal and partition-based with explicitly provisioned throughput, which makes it cheaper but means topics live in a single zone and consumers must understand partitions. Pub/Sub is regional or global, autoscaled, and supports push subscriptions and schemas, but at higher per-message cost.
What are the rate limits for the Pub/Sub Lite API?
Throughput is governed by per-topic and per-partition publish and subscribe capacity, expressed in MiB/s, that you allocate at topic creation or via reservations. Admin API calls themselves are subject to standard Google Cloud project quotas.
How do I seek a subscription back in time through Jentic?
Search Jentic for seek a pubsub lite subscription, load the schema for the admin subscriptions seek operation which maps to POST /v1/admin/{+name}:seek, and execute it with a publish_time or starting offset payload.
Is the Pub/Sub Lite API free?
No, Pub/Sub Lite is billed by reserved publish and subscribe throughput per partition and by stored bytes. Pricing is published on the Google Cloud Pub/Sub Lite pricing page; you pay for capacity even when topics are idle, which is the trade-off for the lower per-message cost.
How do I see how far behind a consumer is?
Use the topicStats endpoints to fetch backlog size per partition and the cursor endpoints to see committed offsets. Subtracting committed offset from head offset gives a per-partition lag in messages.
/v1/admin/{+name}:cancel
Cancel a long-running operation