What shipped
Synapse started as email-only. The roadmap always said push was next, and Phase 8 has been the long body of work to deliver it. Today three things are simultaneously true: the backend push pipeline is in production, the native SDKs are on their public registries, and the channel is bundled into every plan from the Free tier up.
Concretely, this means:
- PYRXSynapse 0.1.0 on Swift Package Manager and CocoaPods Trunk. iOS 14 and newer. Swift actor-based, with a disk-backed offline event queue, anonymous-to-known identity merge, push registration, and cold-start attribution.
- tech.pyrx.synapse:synapse-core and synapse-push 0.1.2 on Maven Central. Android 5.0 (API 21) and newer. A two-artifact split so apps that only need event tracking pay zero footprint for push.
- The send_push step is now a first-class action in the visual flow builder, alongside send_email, wait, condition, and update_contact.
- POST /v1/push/send is available as a transactional endpoint for OTPs, security alerts, and any other one-shot delivery you would not want to model as a flow.
- A push delivery log in the dashboard, a push composer for one-off sends, and a push template editor sit alongside the existing email surfaces.
We tested the full pipeline end-to-end on real hardware before publishing — iPhone over APNs sandbox, Galaxy A32 over FCM — using the local Cloudflare tunnel workflow documented in our developer docs. The send-to-delivered-to-opened lifecycle works on both platforms with timestamps populating correctly.
The SDKs are versioned 0.1.x deliberately. v1.0.0 — and the eighteen-month wire compatibility commitment that comes with it — will follow once we have real-world consumption confidence from design partners and early customers. The 0.1.x releases exercise the full publish pipeline end-to-end (signed artifacts, GPG verification, Sonatype namespace ownership for Maven; tag-resolved Swift Package Manager and pod trunk push for iOS) and prove the toolchain is sound.
Push is a feature, not a tier
The decision we want to flag is this one: every tier ships with push. The Free tier includes 1,000 active devices and 10,000 pushes per month. The paid tiers scale those caps proportionally to the rest of the plan — Starter at 25,000 devices and 500,000 pushes, Growth at 250,000 and 5 million, Pro at 1 million and 25 million, Business at 5 million and 100 million. Enterprise is uncapped.
There is no push add-on. There is no per-MAU multiplier. Web push, when it arrives, lands inside the same bundle. In-app messages, when they arrive in a later phase, do the same. The channel name shows up in the channels array on every paid tier from launch, with the SDK API surface reserved so customers who write against the contract today get the feature without code changes when it ships.
This is a positioning choice with a real opportunity cost. Adding push as a paid tier would have been the textbook upgrade lever. The alternative we picked is simpler: if push is part of the modern customer-communications surface, it should be in the product on every plan. A two-developer team prototyping a Free workspace gets the same push pipeline as a Business-tier customer running a production app — different limits, same primitive.
Bring your own APNs and FCM credentials
Push notifications go out from your Apple Developer team and your Firebase project. You upload your APNs .p8 token-auth key and your FCM service account JSON in the dashboard. From then on, every push carries your bundle identifier and your sender ID — the identity your users already see in their notification settings.
This is the universal pattern across serious push platforms, and it is the only posture consistent with our broader data-sovereignty stance: customer push tokens, push credentials, and message content stay inside Synapse and the tenant's own Apple and Google projects. There is no shared sender. We are not a reseller of someone else's push infrastructure.
Credentials are encrypted at rest using envelope encryption. The dashboard, the API, and every other service hold metadata only — provider, environment, last used, last error. The key material is decrypted exclusively inside the push send worker process. Rotation keeps the prior credential available for thirty days so you can roll back without dropping deliveries, and every credential create / rotate / delete writes an audit row.
One pipeline, two channels
The deeper commitment is architectural. Push delivery telemetry — opens, clicks, failures, unregistration events — emits onto the same event log that carries every customer signal through the platform. The same consumers persist the events, the same loader streams them into BigQuery, the same webhook forwarder fans them out to your endpoints, and the same flow-trigger publisher re-triggers flows when a customer opens a push.
When you branch a flow on a push open, you are branching on the same event envelope shape you would branch on for an email open. Not because the documentation says so. Because the architecture is actually shared. We did the durability work for email once; push extends it for free, and SMS — when it arrives — will extend it again on the same pattern.
The flow processor learned one new step type. The Celery worker learned one new queue. The plan-limits service learned four new columns. The NLT engine learned nothing — short-form push titles, bodies, subtitles, image URLs, and deep links all render through the existing tokenizer and AST. Customers who already wrote an email template get push templating for free.
What it does not do yet
Honesty matters in launch posts. Here is what is on the roadmap rather than the registries today:
- Web push. The VAPID-based browser channel extends our existing browser SDK package, not a new one. It is the next milestone after this launch.
- React Native and Flutter wrappers. Thin TypeScript and Dart wrappers over the native SDKs. Identical public API. Targeted for the next phase of platform work.
- In-app messages. The plan-limit column, the channel-array entry, and the SDK API surface are reserved from launch so the feature can land without breaking changes. Delivery follows in a later phase.
- SMS and WhatsApp. These have real per-send vendor cost and a different pricing conversation. They are not in this launch and will get their own announcements when they are.
How to try it
If you already have a Synapse workspace, the push settings, push template editor, push composer, and push delivery logs are live in the dashboard. Upload your APNs and FCM credentials and send your first push from the composer. The send_push action is also available in the flow builder.
If you are new, the Free tier is the right place to start. 2,000 contacts, 1,000 active devices, 10,000 pushes per month, the full flow engine, the full template language, and the full analytics surface. No credit card.
The SDK reference and integration guides live in the SDK docs. The full architecture writeup is in ARCHITECTURE.md §28 in the public repo.