Core concepts
The most important integration decision is knowing which Engage object owns a piece of state. These boundaries prevent test data from reaching production and prevent a device identifier from becoming a user identity.
Organization hierarchy
| Object | Responsibility |
|---|---|
| Workspace | Team membership, roles, billing, security, audit, and shared governance. |
| Project | Product-level container for environments, media, design tokens, reusable components, and localization. |
| Environment | Operational boundary for audience data, content, credentials, API keys, delivery, analytics, and quotas. |
| App | One platform application inside an environment: Android, iOS, or Web. It owns an SDK app key and platform/provider configuration. |
An environment is the isolation boundary. A development campaign cannot target a production installation unless that application was bootstrapped with the production app key. Use separate environments and app keys for development, staging, and production.
Installation and profile
An installation represents one installed copy of one app. It has a server-issued ID, local durable state, device metadata, push token state, installation attributes, and installation-scoped subscriptions.
A profile represents a person. A profile can own multiple installations and carries profile attributes, tags, profile-scoped subscription choices, events, and audience memberships.
Do not overwrite the installation ID with a user ID. The app requests a short-lived binding code from the SDK and sends it to your authenticated backend. Your backend commits the binding using an Engage access key. See Bind an installation.
App key versus access key
The app key begins with eng_app_. It is embedded in a mobile binary and is intentionally public. It selects the app and environment during bootstrap; it does not grant server privileges.
The access key begins with engk_. It is created in the environment’s REST API settings, scoped to a set of apps, shown once, stored only as a hash by Engage, and used exclusively from trusted servers.
Audience data
Audience selection can use:
- profile and installation attributes;
- profile tags;
- subscription list state and channel consent;
- events and screen activity;
- app and platform;
- segment membership;
- operational eligibility such as privacy, push opt-in, provider configuration, and suppression.
A saved segment is a reusable audience expression evaluated by the backend. A campaign still applies delivery eligibility after matching a segment, so estimated audience size and accepted provider deliveries can differ.
Content and delivery
Engage separates authored content from delivery:
- Push campaign: one-off or scheduled audience send with locale variants, platform overrides, priority, TTL, and tap behavior.
- Transactional template: stable server-callable key with typed variables, localized variants, idempotency, and rate limits.
- In-app experience: server-authored DivKit content plus local triggers, schedule, frequency, priority, and presentation.
- Message Center template/message: immutable summary and detail rendering snapshots stored in an inbox.
- Automation: versioned workflow entered by event, screen, audience, or API and composed of waits, conditions, push, in-app, webhook, profile update, and exit steps.
Drafts and published revisions
Editing and runtime are deliberately separated. Draft changes are not used by released clients until they are published or activated. Published content is versioned so analytics and inbox records can refer to the exact revision a user saw.
Runtime synchronization
The SDK bootstraps an installation, then exchanges an opaque installation credential for synchronized state. Operations and receipts are batched and retried. Remote content and flags are cached locally. Push can wake a platform process, but there is no permanently running Engage process and no persistent WebSocket.