# Braze vs Reteno for Subscription Apps: Pricing, RevenueCat and Migration

Choose between Braze and Reteno by proving three things: the platform can recognise the right subscriber, send the right message for the current entitlement state, and fit the full operating budget. Reteno deserves a focused evaluation for an app-led programme seeking a smaller starting commitment. Braze deserves one when the required channels, governance and orchestration justify its proposed package. Neither wins because a comparison page has more ticks.

Canonical URL: https://www.martechdevs.com/blog/braze-vs-reteno

By [Jafrin Akter Alo](https://www.martechdevs.com/authors/jafrin-akter-alo)

Data Engineer and Co-founder at [Martechdevs](https://www.martechdevs.com) and [Growth and Analytics Partners](https://www.growthandanalytics.com)

[LinkedIn](https://linkedin.com/in/jafrinalo)

Last updated: 2026-10-25

Next step: [Braze Pricing: What Braze Costs, How MAU and Credits Are Billed, and a Quote Checklist](https://www.martechdevs.com/blog/braze-pricing)

For a subscription app, a message can be beautifully personalised and still be wrong. A cancelled renewal may leave access active. A failed payment may be in grace. A refund may affect one product while another entitlement remains valid. Those distinctions matter more than whether a journey builder looks simple in a demo.

This comparison is for growth, CRM and engineering leads running mobile onboarding, trial conversion, renewal recovery and win-back. If the real job is account-level B2B lifecycle messaging, use the [Braze and Customer.io comparison](https://www.martechdevs.com/blog/braze-vs-customer-io) alongside it. Our [lifecycle messaging implementation](https://www.martechdevs.com/lifecycle-messaging) connects purchase state, identity, consent and message ownership before expanding the campaign programme.

## Which platform should your team evaluate first?

Evaluate Reteno first when a bounded mobile journey set can answer the buying question. Evaluate Braze first when the decision depends on a broader operating model across channels and teams. Keep the other as a challenger only if it can meet the same acceptance cases.

| Your situation | First evaluation | What must pass |
| --- | --- | --- |
| One app team proving onboarding and subscription messaging | Reteno | Correct subscription state, device delivery and affordable growth |
| Several teams sharing channels, permissions and message priorities | Braze | The proposed edition supports the actual approval and ownership model |
| Existing Braze works, but renewal cost is uncomfortable | A matched Braze renewal and a scoped Reteno trial | Savings exceed migration and ongoing operating costs |
| Purchase events or identities are already unreliable | Repair the data contract first | Both platforms receive the same correct customer state |

These are practical evaluation priorities, not claims that only one vendor can serve a particular business size. Ask the lifecycle operator to build a real workflow and the engineer to diagnose a failed case. A demo operated entirely by the vendor tells you less about the work your team will inherit.

### Reteno for a focused app programme

- **Best for:** One mobile team proving a bounded journey set.
- **Pros:** A small starting commitment for the evaluation.
- **Cons:** Growth rates and currency need confirmation.
- **Free tier and startup offer:** Startup is free, with the limits below. [Reteno pricing](https://reteno.com/pricing).
- **Choose it if:** Your subscription and delivery tests pass within budget.
- **Skip it if:** Required controls or channels remain unproven.

### Braze for a coordinated engagement programme

- **Best for:** Several teams operating shared channels and priorities.
- **Pros:** Edition options for a more demanding operating model.
- **Cons:** The quote and ongoing work need explicit justification.
- **Free tier and startup offer:** Trials and startup programmes; no permanent free plan. [Braze pricing](https://www.braze.com/pricing).
- **Choose it if:** The proposed package passes the team's actual requirements.
- **Skip it if:** A smaller platform meets those requirements at a better total cost.

Use [the wider Braze alternatives shortlist](https://www.martechdevs.com/blog/braze-alternatives) if neither fits.

## How do Braze and Reteno charge?

Braze contracts combine an edition, MAUs and profiles, Action Credits, services and possible add-ons. Its editions are Go, Select, Pro and Enterprise; rates require a quote. A contractual MAU records an app or web session within a calendar month, with a profile allowance attached. Credits fund channel actions and certain AI features. [Braze pricing](https://www.braze.com/pricing).

Reteno bills by profiles: one correctly unified person with email and a push token counts once. Startup includes unlimited mobile push, 1,000 sends per other channel monthly and 20,000 workflow launches. Growth starts at EUR 30 monthly for 10,000 profiles; above 250,000 profiles, Enterprise is custom-priced. SMS delivery costs extra by country and provider. [Reteno pricing](https://reteno.com/pricing).

Do not treat Reteno's displayed Growth rate as a final invoice schedule. The same page shows approximately EUR 3 per additional 1,000 contacts, USD 3 elsewhere and about USD 1 elsewhere. Request one written currency, tier and incremental-rate schedule. [Growth pricing displays](https://reteno.com/pricing).

| Quote input | Why it matters | What to send both vendors |
| --- | --- | --- |
| Stored profiles | A dormant customer can still need a future message | Identified, anonymous and duplicate populations |
| Monthly activity | Activity and stored population are different quantities | Normal, growth and seasonal peak counts |
| Journey volume | One subscriber can enter several workflows | Entries, eligible steps, channel and suppressions |
| Operating scope | Governance and support are part of the job | Operators, approval needs, integrations and recovery owner |

For a hypothetical app with 60,000 profiles and 35,000 MAUs, the EUR Growth-card interpretation is `30 + ((60,000 − 10,000) ÷ 1,000 × 3) = EUR 180/month`. That is a conditional estimate from one displayed rate, excluding other charges, not a confirmed quote. Never add a euro base fee to dollar increments and label the result a comparable total. [Rate being modelled](https://reteno.com/pricing).

Send Braze the same 35,000 active people, 60,000 stored profiles and channel forecast. There is no honest dollar comparison until the Braze quote and Reteno rate are confirmed. Use the [Braze quote checklist](https://www.martechdevs.com/blog/braze-pricing) to make the request reproducible.

Reteno's own comparison says Braze has no trials. Braze's pricing page explicitly offers them. Use each vendor's own commercial terms to establish availability; do not turn an unsupported competitor average or implementation-duration claim into your budget. [Reteno comparison](https://reteno.com/reteno-vs-braze), [Braze trial availability](https://www.braze.com/pricing).

## How does RevenueCat connect to each platform?

Braze receives a configured RevenueCat integration; Reteno receives a RevenueCat webhook through its event-streaming endpoint. Both routes need identity and event mapping, but they do not expose identical event formats. Preserve a mapping record with the source event, destination event, subscriber identifier and intended journey action.

### RevenueCat to Braze

Configure the Braze instance and an API key with `users.track` permission. Align the Braze user identifier with the RevenueCat App User ID; the optional alias route requires both `$brazeAliasName` and `$brazeAliasLabel`. Keep sandbox routing separate from production messaging. [Braze integration setup](https://www.braze.com/docs/partners/ecommerce/ordering_payments_subscription/revenuecat).

RevenueCat sends lifecycle events such as `rc_trial_started_event` and `rc_billing_issue_event`. New integrations default revenue events to `ecommerce.order_placed`; existing integrations retain their configured custom-event, legacy-purchase or eCommerce format. Changing formats changes the event used by journeys and reporting. Confirm that choice before building triggers. [RevenueCat event formats](https://www.revenuecat.com/docs/integrations/third-party-integrations/braze).

The `rc_subscription_status` attribute represents the subscription associated with the latest event, not a complete multi-subscription entitlement decision. Use the active-entitlement array, listed as `rc_active_entitlement_ids` in the integration's Events table, and verify the delivered field before segmenting. The same page's status section uses a different shortened name. Configured Braze aliases take precedence over App User ID. Avoid duplicate client-side revenue tracking for purchases already sent through the integration. [Status, identity and revenue handling](https://www.revenuecat.com/docs/integrations/third-party-integrations/braze).

Test a customer with two products, not only a customer with one subscription. Expiring one product must not put the entire person into a “lost all access” campaign when another qualifying entitlement remains active. Define which entitlement each journey cares about rather than asking a single customer-level status to describe every product.

### RevenueCat to Reteno

Confirm RevenueCat webhook access first. Webhooks are a Pro integration; legacy plans without that entitlement need to migrate before this route can run. [RevenueCat webhook prerequisite](https://www.revenuecat.com/docs/integrations/webhooks).

Reteno's integration requires a full-access API key in the RevenueCat webhook's Authorization header, with the destination `https://revenuecat.reteno.com/revenuecat/webhook`. Select the intended apps, events and environment. Reteno transforms the payload and matches a contact using configured identifiers such as the external user ID. Keep the credential out of client code and public configuration. [Reteno event streaming](https://docs.reteno.com/docs/revenuecat-event-streaming).

Its examples include `SubscriptionStarted`, `SubscriptionRenewed` and `SubscriptionCanceled`. The finished-subscription example is spelled `SubsriptionFinished`. Confirm the actual event name and parameters in Event history before configuring a trigger; silently correcting that spelling could create a workflow that never starts. A received test webhook proves transport, not every lifecycle mapping. [Reteno event examples](https://docs.reteno.com/docs/revenuecat-event-streaming).

Use your stable customer identifier for the Reteno contact. The API field is `externalCustomerId`; the mobile SDK uses `externalUserId`. It identifies the person, not the order. A contact imported without device information does not yet have the app's device ID or push token attached; the subsequent SDK identity update can join them. [Reteno external ID cases](https://docs.reteno.com/docs/external-id-for-creating-and-updating-users).

Keep anonymous-to-known identity changes and purchase restoration in the test plan. A matching email in two dashboards is weak evidence if the purchase event is still attached to a different internal identifier. Trace one customer from purchase state through the target contact to the actual device receiving the message.

## Which subscription events should change messaging?

Change messaging according to current eligibility, with the source event as the trigger to reconsider it. Keep product access authoritative in the entitlement system. The messaging platform should not become a second, independently invented subscription ledger.

RevenueCat distinguishes cancellation from expiration: a cancellation may concern auto-renewal or a refund. `BILLING_ISSUE` does not mean access has expired. `SUBSCRIPTION_PAUSED` schedules a pause; access removal follows the relevant `EXPIRATION`. A product change need not take effect immediately. [RevenueCat event semantics](https://www.revenuecat.com/docs/integrations/webhooks/event-types-and-fields).

Use these acceptance cases in both candidates. The expected messages are proposed operating rules to adapt to your app, not platform defaults.

| Subscription case | Message decision | What must not happen |
| --- | --- | --- |
| Trial begins with eligible access | Start useful onboarding once | Duplicate welcome from two senders |
| Trial converts to paid | Stop conversion prompts; begin paid adoption | Ask an already paying customer to start paying |
| Renewal is cancelled, access remains active | Offer relevant save or feedback help | Claim access has already ended |
| Payment fails while entitlement remains active | Give the correct recovery instruction | Send a lost-access win-back offer |
| Pause is scheduled for period end | Explain the future state if useful | Announce immediate loss of access |
| One product expires, another qualifies | Reconcile entitlement-specific journeys | Treat the whole customer as inactive |
| Refund or payment recovery changes eligibility | Recheck current state before the next step | Continue an obsolete queued message |

For billing recovery, identify whether the customer needs a store-managed subscription screen, payment authentication or another supported action. A generic “update card” link is not useful if that route cannot fix the actual purchase. The [dunning workflow guide](https://www.martechdevs.com/blog/saas-dunning-workflows) explains message ownership and stop conditions; apply the app store's actual collection route here.

Measure conversion and recovery against the eligible cohort. Counting a renewal after a reminder does not prove the reminder caused it. Keep holdouts or another defensible comparison where feasible, and separate observed outcomes from causal claims. The platform choice should make the needed measurement possible without pretending that a journey report alone proves incrementality.

## How do you prevent duplicate and stale messages?

Give every customer-facing action a stable business key and recheck eligibility before dispatch. Event deduplication and message deduplication solve different problems: a different event can still request the same already-completed message step.

RevenueCat recommends idempotent webhook processing using event IDs and recommends fetching current subscriber information when synchronising status. Sandbox purchases are identified by their environment; one customer can have sandbox and production transactions. Route tests accordingly. [Webhook processing and environments](https://www.revenuecat.com/docs/integrations/webhooks).

For a custom orchestration layer, a useful message key combines the customer, relevant entitlement, journey version and message step. Claim that key atomically with the queued action. An in-memory list or a manual spreadsheet cannot prevent two workers from sending simultaneously. If using a vendor-native journey, demonstrate equivalent repeat-entry and suppression behaviour rather than assuming it from an integration checkbox.

Consider this synthetic acceptance sequence for a renewal-recovery reminder. The customer is known, the channel is permitted and the first snapshot says billing help is still needed. A later snapshot confirms recovery.

| Input or change | Current state at decision | Expected result |
| --- | --- | --- |
| First failure event | Recovery action still relevant | Queue one eligible step |
| Same event delivered again | Unchanged | No second step |
| Different event requests the same step | Unchanged | No duplicate message |
| Recovery arrives before dispatch | Payment issue resolved | Cancel the queued reminder |
| An older failure arrives afterward | Current state remains resolved | Keep the reminder suppressed |
| Current state cannot be verified | Unknown | Hold for reconciliation |

This sequence should produce zero delivered recovery reminders if recovery is confirmed before the send. The point of the test is the state transition, not a claim that either vendor automatically provides these safeguards. Repeat it through the actual configured journey and inspect the send log.

![A purchase event branches on correct identity and environment, holding incorrect mappings. Correct mappings recheck current entitlement and message history, then suppress or reconcile ineligible/already-sent actions and send an eligible action once through its assigned owner.](https://www.martechdevs.com/assets/blog/braze-vs-reteno.svg)

Diagram connections:

- Purchase event reaches the journey to Identity and environment correct?. 
- Identity and environment correct? to Hold and repair the mapping: No. 
- Identity and environment correct? to Recheck entitlement and message history: Yes. 
- Recheck entitlement and message history to Still eligible and not already sent?. 
- Still eligible and not already sent? to Suppress or reconcile the action: No. 
- Still eligible and not already sent? to Send once through the assigned owner: Yes

## What does the mobile implementation need to prove?

Prove delivery, rendering and the destination action in the released app. A contact appearing in the platform is not the same as a usable push subscription. Include app version, operating system, permission state and provider configuration in every test record.

Braze lists push, in-app, Content Cards, email, SMS and WhatsApp among its channels. Confirm the proposed entitlements and credit treatment for your mix. [Braze channel packaging](https://www.braze.com/pricing). Reteno's channel set includes mobile push, in-app, App Inbox, email, web push and messengers. [Reteno channels](https://reteno.com/channels). Its SMS setup can use Reteno or a separately contracted provider. [Reteno SMS routes](https://docs.reteno.com/docs/sms-setting-up).

For Reteno iOS, token handling must match the delivery route: automatic handling for direct APNs, manual handling for FCM or app-managed registration. Mixing APNs and FCM tokens can overwrite the stored token and cause delivery failures. Preserve existing notification handling while integrating the new SDK. [Reteno iOS setup](https://docs.reteno.com/reference/ios).

Test foreground, background and cold-start behaviour. Open a notification while logged out, log in, and verify the destination belongs to the intended customer. Test an unavailable product screen and an outdated app version. The useful failure is one the team can diagnose without sending a campaign to thousands of people first.

Include shared devices. Reteno describes token ownership changing with the identified contact and provides multi-account support for relevant app designs. Validate the intended account's subscription rather than deleting tokens indiscriminately at logout. [External ID and shared-device behaviour](https://docs.reteno.com/docs/external-id-for-creating-and-updating-users).

## What do user reviews add to the decision?

Reviews help identify tasks to test, but their ratings are not a controlled comparison. G2 shows Braze at 4.5/5 from 1,976 reviews and Reteno at 4.8/5 from six reviews. Those populations are too different to infer that the higher score identifies the better platform. [Braze on G2](https://www.g2.com/products/braze/reviews), [Reteno on G2](https://www.g2.com/products/reteno/reviews).

Visible Braze reviewers praise channel coordination and personalisation while raising workflow complexity, analytics and localisation friction. Several displayed reviews are marked incentivised or seller-invited. Use those themes to test your own campaign build, approval and reporting tasks. [Braze reviewer feedback](https://www.g2.com/products/braze/reviews).

Visible Reteno reviewers value custom flows and responsive support, while asking for smoother template localisation and more useful flow-level analysis. With such a small review base, treat those as individual experiences, not reliable estimates of how often a problem occurs. [Reteno reviewer feedback](https://www.g2.com/products/reteno/reviews).

Ask an operator to build one multilingual journey, change a suppression rule and explain an unexpected send. Ask support a realistic diagnostic question during evaluation. These exercises give the reviews a concrete job instead of turning them into decorative star ratings.

## How should a Braze-to-Reteno migration be accepted?

Move one bounded journey only after the replacement passes identity, state and delivery tests. Keep a single sending owner for every step during overlap. Copying templates before defining ownership can create two technically working systems that both contact the customer.

Start with a migration register: identifiers, consent categories, suppression reasons, active journeys, scheduled messages, event names, revenue formats, channel credentials and reporting dependencies. Mark which behaviour should be preserved, repaired or retired. Use the [Braze migration process](https://www.martechdevs.com/blog/braze-to-customer-io-migration) for sequencing, then replace destination-specific steps with the Reteno implementation.

Ship and validate the new SDK in the app release before assuming the whole audience is reachable. Imported contacts and registered devices are different assets. Track adoption of the new app version and maintain an explicit plan for customers who have not upgraded. Retire the old sender only when its remaining responsibilities have a defined destination or stop decision.

People already in a journey need a decision too. Resume from a known step, finish the old journey under controlled ownership, or stop and re-evaluate eligibility. Replaying every historical event as if it just occurred can restart onboarding or recovery messages that should remain completed.

Use this release checklist:

## Checklist

- [ ] Both quotes use the same audience, channel plan and operating scope.
- [ ] Reteno's currency and incremental rates are confirmed in writing.
- [ ] Purchase, app and messaging identifiers map to the intended person.
- [ ] Sandbox activity cannot trigger production customer messages.
- [ ] The Braze revenue format and destination event names are explicit.
- [ ] Trial, cancellation, billing issue, pause, expiration and refund cases pass.
- [ ] Multiple entitlements do not collapse into a false inactive status.
- [ ] Duplicate delivery and recovery-before-send cases produce the expected sends.
- [ ] Push, deep links and in-app rendering work in supported app states.
- [ ] Every overlapping journey has one sending owner and a rollback plan.

Choose the platform that passes those checks at an acceptable total cost. If the uncertain part is RevenueCat mapping or migration ownership, [get the $99 martech audit](https://www.martechdevs.com/pricing) with one real journey specification and the proposed quotes. That gives the review a clear endpoint: a supported design, a costed implementation scope and evidence for the go-live decision.

## Frequently asked questions

### Does Reteno work for a business without a mobile app?

Reteno says its platform is designed for mobile applications and directs businesses without an app to Yespo. [Reteno product scope](https://reteno.com/pricing). If your programme is web-only, start by defining the events, account model and channels you need, then choose a shortlist for that job. A mobile-oriented comparison should not force a web SaaS team into an unsuitable evaluation.

### Will Reteno's free plan cover our production programme?

Count the planned monthly workflow entries and sends by channel, then compare them with the allowances above. Unlimited push does not mean every other operation is unlimited. Include tests, repeated entry and growth headroom in the forecast. The important question is whether the complete programme remains within the agreed limits while preserving suppression and message quality, not whether the first campaign can launch for free.

### Can we keep our existing Braze purchase-event format?

An existing RevenueCat integration retains its configured format until you change it. [RevenueCat revenue formats](https://www.revenuecat.com/docs/integrations/third-party-integrations/braze). Inventory the journeys and reports that use that format before considering a switch. Migrate their dependencies deliberately and reconcile the resulting revenue view. A new recommended format is not a reason to break working triggers without a controlled transition.

### Can Adapty replace RevenueCat in this evaluation?

It can be a separate evaluation, but do not assume the RevenueCat mappings apply unchanged. Verify each destination's supported Adapty integration, event semantics, identity handling and retry behaviour. Then run the same customer-outcome tests with the actual source. Keep the comparison about correct subscription state and messaging; matching a few event names does not prove that cancellations, refunds or restores behave equivalently.

### Should we delete inactive profiles to make a platform cheaper?

Use an agreed retention and suppression policy before deleting customer records. An inactive subscriber may still need a renewal, service or consent-related decision, and deletion can remove useful history. Identify what must be retained, what can be archived and what can safely disappear. Then calculate whether that change affects the actual payable commitment rather than assuming a smaller database guarantees savings.

## Sources

1. [Braze: Pricing and editions](https://www.braze.com/pricing).

2. [Reteno: Pricing](https://reteno.com/pricing).

3. [Reteno: Comparison with Braze](https://reteno.com/reteno-vs-braze).

4. [Braze: RevenueCat integration setup](https://www.braze.com/docs/partners/ecommerce/ordering_payments_subscription/revenuecat).

5. [RevenueCat: Braze integration and revenue formats](https://www.revenuecat.com/docs/integrations/third-party-integrations/braze).

6. [Reteno: RevenueCat event streaming](https://docs.reteno.com/docs/revenuecat-event-streaming).

7. [Reteno: External IDs and device matching](https://docs.reteno.com/docs/external-id-for-creating-and-updating-users).

8. [RevenueCat: Event types and fields](https://www.revenuecat.com/docs/integrations/webhooks/event-types-and-fields).

9. [RevenueCat: Webhooks](https://www.revenuecat.com/docs/integrations/webhooks).

10. [Reteno: Channels](https://reteno.com/channels).

11. [Reteno: SMS setup](https://docs.reteno.com/docs/sms-setting-up).

12. [Reteno: iOS SDK setup](https://docs.reteno.com/reference/ios).

13. [G2: Braze reviews](https://www.g2.com/products/braze/reviews).

14. [G2: Reteno reviews](https://www.g2.com/products/reteno/reviews).