Copy page

Audience & data

Data connections

Data brings your tools, message activity and player events together. Open Data in your app to find Integrations, Event Streams, Data Feeds, and Events & Conversions.

You want to…	Start here
Bring Amplitude player events or audience groups into OpenPush	Integrations → Amplitude → Receive events
Send message activity to Amplitude	Integrations → Amplitude → Send events
Send message activity to your own server	Event Streams
Put a current balance, score or recommendation into a push	Data Feeds
Explore player events and measure conversions	Events & Conversions

Browse Add integration using search and category filters, or switch to Your connections to find a saved setup. The catalogue shows available integrations and existing OpenPush tools. Use Disable on a saved connection to pause it; its settings and history are retained. Enable resumes a previously tested connection. Each connection is controlled separately, including incoming and outgoing Amplitude connections.

Existing SDK event methods, Journeys, tags, segments, dynamic content tables and message delivery keep their existing roles. A connection is an optional addition to those features.

Set up a connection

Every connection follows three steps: choose the destination or source, choose the data, then check the result. Save settings creates a draft. Run test checks the saved version. Only a successful test enables Turn on connection. Editing settings returns the connection to draft and requires another test.

App admins manage and test connections, receiving keys and event storage. Managers can inspect connections, export data and create conversion metrics. Viewers can inspect reports. Shared sample apps keep each workspace's connections, events and reports separate.

Pause stops new outgoing events and pauses queued delivery work. Resume retains previously queued work; events that occurred while paused are not replayed. A request already in flight can finish. Pause before deleting a connection. Deletion removes its delivery queue and logs; it does not delete incoming player events, previously applied cohort tags or saved message feed snapshots.

Amplitude: bring player events in

1. In OpenPush, choose Receive events and name the connection.

2. Check the incoming field names. The defaults match Amplitude's event format:

   OpenPush needs	Default Amplitude field
   Event name	event_type
   Your user ID	user_id
   Event properties	event_properties
   Event time	time
   Unique event ID	uuid

3. Optionally enter a comma-separated list of event names to receive. Additional property mappings use dot paths, such as user_properties.level. Fixed properties are merged into each event; mapped properties take precedence.

4. Save, then test an example event. Use a user ID that already exists as an OpenPush External ID. A test checks the identity and mapping without recording the event or starting a Journey.

5. Turn on the connection. Copy its receiving URL and key into an Amplitude Webhook destination, using an Authorization: Bearer <receiving-key> header. Follow Amplitude's Webhook destination guide. OpenPush does not require or claim a native Amplitude destination listing.

The key is shown when created or replaced. If you lose it, use Replace receiving key and update Amplitude. The old key stops working immediately. Use the HTTPS address of your hosted OpenPush server; Amplitude cannot reach a localhost review URL.

Events match existing users; this connection does not create users. Register the user through the existing OpenPush SDK or subscription API first. Missing users or invalid mappings are shown as dropped events in the connection log. Incoming activity reuses custom-event ingestion, including the 50-event batch limit, 2 KB property limit, validation and Journey hook. Requests are limited to 256 KB. Event time accepts ISO 8601, Unix seconds or milliseconds. A supplied unique ID deduplicates retries within the connection while the event is retained. Replays after event retention has removed the original can be accepted again.

The response reports accepted and dropped items independently. HTTP 200 can contain dropped items: inspect the response rather than treating status alone as proof that every event was recorded. Rate-limited requests are refused; retry them after a short delay.

Amplitude audience groups

Enable Sync audience groups and configure a Cohort Webhook sync in Amplitude, using the same URL and authorization header. Availability depends on your Amplitude plan.

OpenPush accepts the documented cohort_id, cohort_name, in_cohort, computed_time and users[].user_id payload. It stores membership as a stable amplitude_cohort_… user tag with value true. The connection report shows each group's tag and member count. Use that tag in the existing segment builder. Removing a member removes that tag; unrelated tags remain intact. Duplicate and older membership updates do not replace newer ones. Each request accepts up to 1,000 existing users. These updates do not count as app sessions.

Amplitude: send message activity out

Choose Send events, enter your Amplitude project API key, and select the United States or European Union region. Then choose the message activity to send, save and test. Tests are clearly identified with sample event and user IDs and will appear in the receiving project when used outside local dry-run mode.

OpenPush sends Amplitude HTTP V2 events with a stable insert_id, timestamp, message properties and user details. The user's External ID is used when available, with the OpenPush user ID as a fallback. This is independent of the incoming connection: set up both if you need data in both directions.

Event Streams: send to your own system

Choose a public HTTPS URL and request method. Add authentication as key/value rows under Request headers & authentication. Existing header values stay hidden; choose Replace saved headers to change them. Each event shows its payload name below the label. Email and SMS options are visible but disabled until those channels are supported. Choose activity from OpenPush's supported channels:

Channel	Available activity
Push	Provider acceptance, device receipt, display confirmation, opening, final send failure, invalid device token
In-app messages	Impression, interaction, carousel page display
Live Activities	Provider acceptance, device receipt, display confirmation, opening, final failure, invalid activity token

Device events depend on receipts emitted by the installed SDK and platform. OpenPush does not invent a device receipt from provider acceptance. The current SDKs do not all emit every in-app page or Live Activity receipt; an available server event can remain empty until instrumentation sends it. Email, SMS and RCS are not OpenPush sending channels and are not offered.

Use Limit to certain messages or templates to enter IDs. If either list matches, an event is included. Empty lists include all messages with the selected activity.

Choose the data format:

• Pick fields visually: give each destination field a name and choose its OpenPush source. Numbers, objects, booleans and missing values retain their JSON types.
• Full event, message and user details: include the event snapshot and its related context.
• Custom JSON with personalization: use the existing Liquid renderer and the json filter for safe serialization, for example {"event_id": {{ event.id | json }}}.

The field picker exposes event IDs, timing, player and subscription identifiers, platform, interaction details, message details and user properties. Preview shows illustrative data. A saved connection test sends a real request with X-OpenPush-Test: true; it does not count as a real delivered event. URL and header values can use the same event context. Return a prompt 2xx response with uncompressed JSON or text. Redirects are not followed.

Delivery and recovery

The existing send/receipt transaction creates a durable event and delivery queue entry. Network work runs separately from provider delivery. Each request carries X-OpenPush-Event-ID; retries keep that ID. Receivers should deduplicate by it because delivery is at least once, including after worker recovery.

Temporary network failures, HTTP 408, 425, 429 and 5xx responses retry up to six times after the initial attempt, with delays of 10 seconds, 30 seconds, 2 minutes, 10 minutes, 30 minutes and 1 hour. Numeric Retry-After can extend a delay up to one day. Other non-2xx responses fail immediately. Retry failed deliveries lets an admin explicitly try failed events again on an active connection.

After 10 consecutive failed attempts, configured administrator email receives an alert. After 20, the connection moves to Needs attention and pauses. Fix the destination, run a successful test, turn it on, then retry failures as needed. Email requires the existing OpenPush mailer to be configured.

Reports show queue states, hourly delivery activity, date/result filters, and request/response details. Tests remain separate from actual delivery totals. Logs and completed queue entries are retained for 30 days; pending work is retained until resolved. Requests have bounded time and response size. Destination credentials are encrypted using OpenPush's existing credential storage, and sensitive headers and known secret values are hidden from reports.

Data Feeds: personalize with fresh data

1. Name the feed and enter an HTTPS endpoint and method. Add request headers as key/value rows. The URL, body and headers may use existing user personalization fields.
2. Give the returned object a short data name, such as rewards.
3. Choose what should happen if the endpoint fails: skip that recipient with a render error, or use saved fallback JSON.
4. Choose Find a test subscription to pick a saved test device, or enter an existing subscription ID. The endpoint must return a JSON object no larger than 50 KB. Test failures stay visible even when fallback data is configured.
5. Turn it on. In the existing push composer, choose Personalize to insert fields discovered from the last successful test. You can also write {{ data_feed.rewards.points }} in title, body, image URL or deep link.

A composer preview uses the saved test response and makes no external request. Sending fetches current data for that recipient. The first successful or fallback response is saved per message, subscription and data name so retries keep the same content. Fields without an active feed are refused rather than silently sent as blank. Unreferenced feeds make no network requests. Feed fields work in direct and Journey push sends; they are not fetched for in-app messages or Live Activity payloads.

Use dynamic content for reusable lookup tables; use feeds when the value must be fetched at send time. These both use the same message renderer.

Events & Conversions

The Event catalogue groups received events by name, with source chips for each integration. Expand a row to see the latest payload. Event activity shows individual occurrences; each row expands independently to reveal its payload. Search event names or user IDs and filter by source and period. Custom range accepts From and Through dates, includes the whole UTC end date and supports up to 365 days. The chart and event rows follow the same range.

Each catalogue row has a three-dot action menu:

• View event details opens a side panel with stored counts, the latest payload, sources, recent activity, Journey usage, conversion metrics and storage settings. Panel counts cover retained history, while catalogue counts follow the current filters.
• Send test event records an event for an existing user's external ID through normal ingestion. It is labelled Test event and can start matching live Journeys and count toward conversion metrics. Retrying the same submission does not create a duplicate.
• Create Journey opens a new draft in the existing Journey editor with this event as its entry trigger.
• Create conversion metric opens the existing metric form with the event selected.
• Delete event asks an admin to confirm removal of all stored occurrences with that name in the current app and workspace. Journey definitions, conversion metrics, recorded conversion results and collection settings are retained. New activity can add the event back to the catalogue.

Viewers can inspect events; managers can send tests and create drafts or metrics; admins can also delete stored events and change storage settings. Existing SDK/API events and incoming Amplitude events share this explorer.

Choose Create conversion metric on an event, or create a metric in Conversions. Count occurrences or sum a numeric property such as price. Select separate push and in-app attribution windows, from zero to 30 days; zero disables that channel's window. Only events received after metric creation with eligible timestamps contribute. Non-numeric, missing or non-finite values are skipped for value metrics.

The Conversions list shows the event, measurement method and tracking status. Search by metric or event name, and use Filters to show a tracking status or measurement method. Expand a metric for its last 30 days of results and message connections.

Managers can use the three-dot menu to Rename, Pause tracking, Resume tracking, send a test event, or change Message windows. Pausing affects only new conversion collection for that metric: incoming events, Journeys, other metrics and saved results continue unchanged. Resuming counts new events without backfilling events processed while paused. Message windows selects a metric and updates its push and in-app matching durations for new conversions only. The event and measurement method remain fixed so existing results retain their meaning. Admins can also remove a metric.

The most recent eligible click receives attribution. Other qualifying clicks, receipts or impressions count as influence. Events with no qualifying touch appear as unattributed. Each total counts an event once; attributed and influenced groups can overlap and should not be added together. These metrics measure custom events; existing automatic sessions and click statistics remain in their existing message and dashboard reports.

Under Event storage, choose unlimited history or an explicit retention period, or stop receiving an event name. Unlimited and continued collection are the defaults. Reducing retention deletes older events during the hourly cleanup. Stopping an event also stops new Journey triggers and conversion collection for that event. Saved conversion results survive event cleanup. Removing a conversion metric removes its report, leaving the original events.

Export events downloads the latest 10,000 events as CSV. Export settings & history downloads the dedicated Data JSON archive, including connection settings, retained stream history, cohort mappings and conversion evidence, without credentials. The general app archive continues its existing import/export contract; the dedicated Data archive is for inspection and backup and is not a restorable connection import.

API and local review

Connection management endpoints live under /v1/apps/{app_id}/data/connections and use the existing X-OP-API-Key authorization. Create with POST, update a saved connection with PUT and its current revision, read reports with GET, test with POST to /test, and operate using POST to /actions/activate, /pause, /retry, /delete or /rotate-token. Incoming sources use their separate Bearer key at /v1/apps/{app_id}/data/sources/{connection_id}/events. Shared sample apps require the owner-scoped console for connection management.

Local DRY_RUN=1 refuses external destination requests. The development-only OP_DATA_ALLOW_LOOPBACK=1 permits a local HTTP test receiver when dry-run mode is enabled. This lets you verify the feature without contacting Amplitude, Apple or Google. Real Amplitude credentials, public endpoint reachability and device receipt availability must be checked in the deployment that will use them.