Compliance Event Stream

Open a compliance event stream

Changed on

Opens a stream delivering events proving data-safety regulation compliance for email and SMS channel-related events (registration, unsubscription, etc.).

Unlike a standard event stream, a compliance event stream uses basic authorization, like API calls to https://go.urbanairship.com/api.

post/api/events/general

Request

Headers

X-UA-Appkeystring required

The application key.

The app key for the project you want to return compliance events for.

Request body

resume_offsetstring

The offset where the stream should begin. The offset is an identifier relevant only to the data stream. The first event in the stream will be the next element satisfying the filter and subset conditions with an offset field greater than this value. Only specify resume_offset if start is absent.

start'EARLIEST' | 'LATEST'

Specifies that the stream should start at the beginning or the end of the application's data window. Only specify start if resume_offset is absent.

Response

The response to a successful request is an unending stream of newline-delimited JSON. Each non-empty line in the response represents a single compliance event. Unlike events in a normal event stream, this endpoint returns events of the compliance type, and is open to SMS and email customers. As long as the connection is open, Airship will continue to write to the event stream.

If a stream records no events for a period of time, the API will write a blank line (a single newline character) to the connection to prevent it from being closed for inactivity. If the enable_offset_updates field in the request is true, then the blank line is replaced with an OFFSET_UPDATE event. These events have no body or device field, and always have occurred and processed times indicating when they were sent. The offset field will contain the offset of the last event considered for inclusion in the stream whether or not it was actually sent. This may be useful to track position in the stream when using a filter which removes much of it.

You should not store these events; they will be different for every connection even if requests are identical. OFFSET_UPDATE events are not subject to filters, and are delivered even if not specified in the list of events you want to return. You should always check the type field before handling any delivered event.

If you do not receive data or new line characters for ninety seconds, close the connection and reconnect.

Changes

    • breaking

      added to the response property oneOf list for the response status

    • info

      added the optional property /// to the response with the status

    • info

      added subschema #1 subschema #2 to the response body allOf list for the response status

    • info

      removed subschema #1 subschema #2 from the response body allOf list for the response status