What does OneSignal integration connect?
OneSignal integration connects application SDKs, customer identity, channel subscriptions, attributes, and behavior events. SDK installation and customer-aware messaging are connected implementation stages.
Application teams define device and screen behavior; server teams confirm accounts and transactions; CRM teams define audiences and guidance. A shared identity and event contract keeps messages consistent with actual product state.
Separate customers, devices, and subscriptions
To recognize a customer after changing phones or adding email, connect your account identifier to the OneSignal subscription model.
User
The customer-level entity that groups channel subscriptions. Customer attributes belong here; individual subscription state determines whether a destination can receive a message.
Subscription
A messaging destination such as a mobile app, browser, or email. A customer can have several, so subscription count and registered customer count are not interchangeable.
External ID
A stable account identifier chosen by your service. Connect the authenticated account ID to login so devices and channels belong to the same customer.
Attributes describe state; events describe actions
“Is a paid customer” and “just paid” are different data. Separating Tags from Custom Events clarifies audience selection and action-triggered automation.
Tags: current attributes
Manage values such as plan or preferred_language for targeting and personalization. Assign the source system and define when values are updated or removed.
Custom Events: actions that happened
Send actions such as subscription_started or booking_confirmed. Specify the event name, trigger, customer identity, related identifiers, and property types.
Custom Events is available on paid plans; storage has separate billing conditions. Historical event segmentation is Early Access, so confirm account enablement and storage requirements.
Divide responsibilities between SDK and server
Sending the same action from both the app and server can start duplicate guidance. Use the system that confirms the transaction as its source of truth.
Application and website
Implement SDK initialization, authenticated login and logout, permission requests, click navigation, and app behavior. Check that account switching clears the previous customer context.
Server and data systems
Handle confirmed payment or booking events, attribute updates, retries, and duplicate prevention. Assign event ownership and identifiers for matching subsequent actions.
Operations and security
Distinguish the public App ID from secret API keys. Keep API keys in secure server storage, never in application code, and separate test and production configurations.
Validate more than one successful delivery
A delivered test message is only part of readiness. Check account transitions, subscription settings, and failures that real customers encounter.
Account transitions
Check anonymous use, login, logout, and login to another account. Confirm that the intended customer owns each subscription.
Permissions and navigation
Test allow, deny, and unsubscribe states, application states, login-required destinations, and deleted or expired content.
Data and repetition
Check missing and duplicate events, retries, incorrect property types, and stopping after completion. Keep records that the operations team can use.
Design example
From a confirmed booking to visit preparation
A design example for a service where customers request a booking in an app and a server confirms it. A button click and a confirmed booking are separate actions.
Connect the account
Associate the authenticated account identifier and check the customer’s channel subscriptions.
Send server confirmation
After saving the booking, send booking_confirmed with booking_id and only the properties needed for guidance.
Guide the next action
Start from the event and link to that booking’s detail page. Define how changes and cancellations stop follow-up.
Test changing conditions
Test server retries, multiple bookings per customer, and links opened while logged out. Confirm that actions from different bookings do not mix.
Limit data to the fields needed for guidance and decision rules. Agree on the field list with data owners to avoid unnecessary sensitive information in events or message content.
Implementation with IXC
IXC supports integration and application changes
As an official OneSignal partner in Korea, IXC supports SDK integration, application features, deep links, server and customer data connections, QA, and operations. Scope and responsibilities follow your existing systems.
Integration design
Map account identity, device subscriptions, Tags, events, consent state, and source systems.
Implementation and migration
Connect application and server code and reconcile customer identifiers and workflows with the existing messaging tool.
Validation and handover
Provide test scenarios, verification records, error-handling guidance, and campaign change procedures for operators.
Design and testing resources
Frequently asked questions
Is SDK installation enough for customer-specific messaging?
The SDK connects subscriptions and application behavior. Customer-specific guidance also needs identity, relevant attributes and events, channel setup, and subscription state. Development scope depends on your existing login and server architecture.
How do several devices connect to one customer?
Use a stable service account identifier as the External ID. Associate the same account during login to group its subscriptions, and implement logout and switching to another account as well.
Should Tags store every customer action?
Tags fit current customer attributes. Use Custom Events for individual actions that need timing and properties. Check storage and event-segmentation conditions, then define only the data required by the use case.
Can IXC help when our application developers are unavailable?
IXC can support SDK integration, application changes, deep links, server events, and customer data connections. Scope depends on your application technology, source access, release process, and existing messaging tools.