Streaming responses

Enable a streaming endpoint

1. Open the endpoint and choose Update endpoint.

2. Set Response mode to Stream and save.

3. Add Send stream event where an update should be sent.

4. Supply its data and, optionally, an event name, ID or reconnect hint.

5. Add Close stream when the response is complete.

6. Publish the endpoint when it is ready for your app.

Existing endpoints use Standard by default. Streaming is an endpoint response mode; use it only when the caller understands event streams. Customer authentication, permissions and rate limits still apply.

Click the Send Stream Event command row to edit its inputs. Set data to the value to send; event, id and retry are optional. The example below sends a progress update with two data fields.

Streaming responses use status 200 and the event-stream response type. You can add safe custom response headers, but cannot override the stream’s content type, content encoding, caching or buffering settings. Incompatible response status or reserved headers are rejected.

Once the first update has been sent, the response has already started. Later failures cannot replace it with a normal error response. Your app should handle an interrupted connection and check any lasting result in your database.

Preview updates

In the API Client, choose the endpoint and enable Preview event stream before sending. Updates appear as separate events as they arrive. Use the request's normal customer authentication. Select Cancel to close the connection.

The preview shows up to 20 events or 64 KiB over 60 seconds. Reaching this preview limit closes its connection; it does not mean a full production response has to contain only 20 events. Values are shown as text rather than executed as page content.

An endpoint's editor test also shows a bounded stream preview with its test results. Tests use the endpoint's selected test-data behavior; they do not turn the editor login into a customer login.

Read another service's event stream

Use Streaming HTTP Request through a published API endpoint to consume another service’s event stream. It can also sit in a server function called by that endpoint. This command does not run external streams in editor tests, events, background jobs or test suites. For a complete check, publish a synthetic endpoint in your Dev workspace and call its local or development API address with safe test data.

Configure the external request’s URL, method, headers, body and timeout using the familiar HTTP request controls. Use headers with secret-variable references when the service requires authentication. Connector accounts and file uploads are not supported by this command. Supported body formats are None, JSON, HTML, XML, Form (application/x-www-form-urlencoded) and Text.

Send Stream Event and Close Stream still support the endpoint editor’s bounded test preview; that preview does not open an external stream.

Choose an event variable name, such as event, and add commands inside the container. They run for each received update. The event contains event, data and, when supplied, id and retry. data is text; parse it only when the service says it contains JSON or XML.

Use Continue loop to skip to the next update, or Break loop to stop reading. The event variable is available inside this container. Afterwards, its Return as value contains event_count, byte_count, status and closed.

The service must be publicly reachable and provide a supported event stream. Existing external-request security restrictions still apply. The stream has time and size limits so it cannot run forever.

Choose streaming or realtime

A stream belongs to one HTTP request and ends when that request finishes. Realtime channels are useful when an app needs separate live notifications from multiple workflows over time. Store important data in your tables in either case.