Create the app
Establish the environment and company ownership boundary.
Developer hub
Integrate once, then keep shipping the game.
Use explicit APIs, scoped credentials, durable delivery, and observable outcomes instead of rebuilding provider orchestration around every title.
Illustrative integration consoleReady to send
Overview
Audience
Messages
Delivery
Settings
Live workspace
mythic-forge-prod
Provider
FCMDevices
24.8kAPI keys
03Current flow
Health checkProvider configured
Test pathNo production send
Event APIScope events:write
Example data for product illustration. Not customer performance.
The integration boundary should be boring in the best way.
Your backend supplies trusted identity and game context. PushHub handles provider adaptation, dispatch state, retries, delivery records, and operator visibility.
How it works
Four milestones to a responsible first campaign.
Configure delivery
Store the app-owned FCM or APNs credential and run diagnostics.
Register devices
Send tokens, player IDs, platform, locale, version, and useful attributes.
Operate and observe
Issue scoped keys, fire events, launch campaigns, and inspect outcomes.
Capability depth without the fine-print surprise.
Current and planned capabilities are labeled directly, so teams can evaluate PushHub without confusing vision for availability.
REST and OpenAPI
Build against documented resources and a machine-readable contract.
Provider abstraction
Use one PushHub surface while each app retains its own FCM or APNs configuration.
Observable dispatch
Trace normalized notification outcomes and recipient-level attempts.
Typed JavaScript client
Use the early JavaScript SDK where it fits, with REST remaining the stable baseline.
In the game
Clear ownership between product and platform teams.
Game backend
Own authoritative player state, events, identity, and commerce decisions.
PushHub
Own messaging operations, provider delivery, retry, audit, and reporting.
Game client
Own permission UX, token registration, deep-link behavior, and optional receipts.
Production guidance includes the failure path.
The developer journey explains missing provider configuration, invalid tokens, transient retry, idempotency, quotas, and the difference between acceptance and receipt.
App-owned credentials
No shared production Firebase fallback is enabled.
Database-owned intent
Dispatch can recover when Redis wake-ups are lost.
Bounded processing
Leases, batches, and retry budgets limit duplicate and runaway work.
Questions teams ask before they commit.
Start with app setup and device registration, then add campaigns or event triggers when the audience is healthy.
Give your backend a calmer push boundary.
Start with one app, one meaningful moment, and one audience worth reaching.