Pub/Sub has both traditional REST/HTTP and gRPC interfaces. If you don't want to use our client libraries to access the Pub/Sub API, you have the option of writing your own client libraries that use its REST/HTTP or gRPC API surface. We recommend this approach only if your programming language or other needs are not met by the provided client libraries.
You can generate your own gRPC client libraries in any gRPC-supported language for the Pub/Sub API from its .proto service definition using these resources:
- Pub/Sub service definition
- gRPC documentation: Everything you need to generate and use your own gRPC client code
- RPC API Reference: Language-independent overview of the RPC surface
There are a number of options for interacting with a service's REST interface. To create your own clients, use the following resources:
- REST API Reference
- Guidelines for working with Google HTTP APIs
- API Discovery Service: Exposes machine readable metadata about the REST/HTTP API surface, useful for creating client libraries, tools, and plugins.
- Directory of client samples built with REST/HTTP APIs and the Google API Discovery Service.
Pub/Sub has global and regional service endpoints.
The global REST/HTTP endpoint is
the global gRPC endpoint is
Requests to the global endpoint originating from within Google Cloud are routed to the Pub/Sub in the region where they originate. Examples of origins considered within Google Cloud include clients running on Compute Engine or App Engine. Requests to the global endpoint made over Interconnect are routed similarly to requests originating in the region associated with the interconnection. In case Pub/Sub becomes unavailable in a region, requests originating within the same Google Cloud are not load balanced to a different region.
Requests sent to the global endpoint from outside of Google Cloud are routed to a nearby available region. The requests may be routed to a region with insufficient project quota for the request type. The region is also not guaranteed to be the closest geographically.
We recommend using regional endpoints as an alternative to the global one in the following cases:
- High volume applications running outside of Google Cloud that require sufficient quota in all regions where traffic might be routed.
- Applications with multiple subscriptions and subscribers that are running in a region different from the region where data is published. Publishers can publish messages via the regional endpoint corresponding to the subscribers' region in order to reduce egress costs.
- Applications which require that data be processed in a specific region.
To send requests directly to a region, use the following regional Pub/Sub endpoints:
|Region||REST/HTTP endpoint||gRPC Service|