---
schema_version: "1"
id: e44f3bb4917816a8d6182093bce5b266cd0af2557390c0a7296496f158827586
title: PublishStream RPC Method
collection: developer
version: current
locale: en-us
portal_url: https://docs.salesforce.com/developer/current/en-us/event-bus/pub-sub-api/references/publishstream-rpc.md
canonical_url: https://developer.salesforce.com/docs/platform/pub-sub-api/references/methods/publishstream-rpc.html
source_site: developer.salesforce.com
content_type: documentation
content_hash: cf183f5cdc398f6b6187603ef2d0ed0b03e0848aeeac841669f1914d2f415c4b
products:
  - Pub/Sub API
  - Event Bus Docs
---
# PublishStream RPC Method

The `PublishStream` method uses bidirectional streaming. It can send a stream of publish requests while receiving a stream of publish responses from the server. Use PublishStream to achieve a higher publish rate than with Publish.

```
rpc PublishStream (stream PublishRequest) returns (stream PublishResponse);
```

The first PublishRequest of the stream identifies the topic to publish on. If a subsequent PublishRequest provides topic_name, it must match what was provided in the first PublishRequest. Otherwise, the RPC sends an error with an INVALID_ARGUMENT status.

The server returns a PublishResponse for each PublishRequest when publishing is complete for the batch. It isn’t necessary for a client to wait for a PublishResponse before sending a new PublishRequest. Multiple publish batches can be queued up. This behavior allows for a higher publish rate because a client can asynchronously publish more events while publish operations are still in flight on the server side.

The PublishResponse holds a PublishResult for each event published that indicates success or failure of the publish call. A successful status means that the event was published and is in the event bus. A failed status means that the event failed to publish.

For more information about the fields in PublishRequest and PublishResponse, see the [Pub/Sub API proto file](https://github.com/forcedotcom/pub-sub-api/blob/main/pubsub_api.proto).

## Publishing Required Fields

The `PublishStream` method doesn’t enforce the presence of required custom event fields in the event payload. If you publish an event without including a required custom field, the publish call succeeds and the received event contains the field with a null value. For system fields, the `CreatedDate` and `CreatedById` fields are required in the event payload. If you publish an event without these system fields, the call fails.

## Order of Events

For each batch of events in PublishRequest, the order of results in PublishResponse corresponds to the order of events in the publish request. You can correlate each successful or failed result with the corresponding event in the publish request.

When you publish multiple batches of events, each in a PublishRequest, the order of batches published matches the order of batches received.

## Identify an Event with ProducerEvent.id and PublishResponse.correlationKey

The event `id` field in a PublishRequest, `ProducerEvent.id`, identifies an event published. It can be either system-generated or user-provided. If you don’t specify an `id` value in the PublishRequest and the publish call succeeds, `PublishResult.correlationKey` is populated with a system-generated UUID. If the publish call fails, `PublishResult.correlationKey` is empty. When publishing an event, you can specify a custom `id` value in `ProducerEvent.id`. If you set a custom `id`, the `PublishResult.correlationKey` field in the returned PublishResponse is the custom `id` value for successful and failed publish calls. The custom `id` value can be any string up to 36 characters. We recommend specifying a unique `id` value, such as a UUID.

## Retry Publishing Failed Events

If the publishing fails due to a malformed event payload or a missing `schema_id` field, fix your request and try publishing again. If the cause of the publishing failure is due to a temporary server issue, retry publishing. To be able to retry publishing events, set the ProducerEvent `id` value in PublishRequest in the PublishStream call to a custom `id` value. When the `PublishStream` call fails, the returned PublishResult in PublishResponse contains the `correlationKey` field set to the `id` value that you provided. To identify the event published, match `PublishResult.correlationKey` with `ProducerEvent.id` (the event ID). You can then republish the event. It’s advisable to limit the number of retries so that your publish calls don’t execute too many times in case the publishing keeps failing.

## Keeping the Publishing Stream Alive

To hold onto the stream, a client must send a valid publish request with one or more events periodically. The server keeps the stream alive as long as it has been less than 30 minutes since the last PublishRequest that the client sent or since the last PublishResponse that the server sent. When the client is notified of the stream closure, it must make a new `PublishStream` call to resume publishing.

## Handling Errors

If an error occurs, the long-lived connection is stopped. Retry the `PublishStream` RPC method call to create a new long-lived connection. For more information, see [Handle Errors](/docs/platform/pub-sub-api/guide/handling-errors.md).

**See Also**

- [Java Quick Start](/docs/platform/pub-sub-api/guide/qs-java-quick-start-parent.html)