Integration · Messaging and marketing

Send in-app purchase events to Iterable

RevenueDot sends every subscription step to Iterable as a custom event such as rc_initial_purchase_event or rc_renewal_event, with revenue in US dollars in dataFields. Tick one box and paid steps go to Iterable as purchases instead. Each event also sets rc_subscription_status on the user. You paste a server-side API key, and failed sends retry for you.

What teams do with it

  • Start a journey when a trial starts and stop it when the trial converts.
  • Email customers with a billing issue or a cancellation, using rc_subscription_status in a segment.
  • See purchase revenue in Iterable's revenue reports by sending paid steps as purchases.
  • Keep journeys that trigger on the rc_*_event names working after a switch from RevenueCat.

What RevenueDot sends

  • A custom event per step through POST /api/events/track: rc_initial_purchase_event, rc_trial_started_event, rc_trial_converted_event, rc_trial_cancelled_event, rc_renewal_event, rc_cancellation_event, rc_uncancellation_event, rc_non_subscription_purchase_event, rc_subscription_paused_event, rc_expiration_event, rc_billing_issue_event, rc_product_change_event and rc_test_event.
  • dataFields: product_id, store, environment, period_type, entitlement_ids, transaction_id, original_transaction_id, country_code, revenue (USD), price_in_purchased_currency, purchased_currency, purchased_at, expiration_at, cancel_reason and expiration_reason.
  • With Send paid events as Iterable purchases ticked, initial purchases, trial conversions, renewals and one-time purchases with revenue above 0 go to POST /api/commerce/trackPurchase with one item (id, sku, name, price, quantity 1) and a total. Refunds stay events with negative revenue.
  • rc_subscription_status on the user through POST /api/users/update: active, trial, cancelled, grace_period, expired, paused and the other statuses.
  • Identity: $email as email when set, else $iterableUserId, else the app user ID as userId. $iterableCampaignId and $iterableTemplateId attribute the event to a campaign and template.

Setup

How to connect Iterable to RevenueDot

  1. 01

    Create a server-side API key

    In Iterable, create a server-side API key. For sandbox events, create one in a second Iterable project.

  2. 02

    Open the integration

    In RevenueDot, open Integrations → Iterable.

  3. 03

    Enter the keys

    Fill in Server-side API key and, for sandbox events, Sandbox server-side API key.

  4. 04

    Pick the data center

    Choose the Data center, US or EU.

  5. 05

    Choose events or purchases

    Tick Send paid events as Iterable purchases if you want Iterable's revenue reports. Set Sales reporting.

  6. 06

    Connect and test

    Click Connect Iterable, then Send test event and check the delivery log. Set $email in your app so Iterable matches customers by email.

The Iterable integration page in the RevenueDot dashboard, with its settings form
Captured from the RevenueDot dashboard with demo data.

How Iterable deliveries are retried, logged and replayed

  • Retries: timeouts, 408, 425, 429 and 5xx answers retry after 5, 10, 20, 40 and 80 minutes. Any other 4xx fails at once, because sending the same request again cannot work. Fix the setting, then replay.
  • Delivery log: each delivery shows the request with every secret replaced by [redacted], the partner's answer, the HTTP status, the time taken and the number of attempts.
  • Skipped, with the reason: when there is nothing to send, such as a missing device ID, the delivery is marked skipped and says why. Retry sends it after your app sets the attribute.
  • Replay: Replay failed resends failed and skipped deliveries in bulk.
  • Sealed credentials: keys and tokens are encrypted with AES-256-GCM on the server and never shown again. The dashboard shows only the last four characters.
  • Safe retries: the event ID is Iterable's event or purchase id, so a retried event updates the same record instead of adding one.
  • Rejections: Iterable answers code, and any code other than Success is logged as a rejection.

FAQ

Iterable and RevenueDot

How do I send in-app purchase events to Iterable?

Create a server-side API key in Iterable, open Integrations → Iterable in RevenueDot, paste it, pick the data center and click Connect Iterable. Every purchase, trial, renewal, cancellation, refund and billing issue is then sent as an rc_*_event custom event, and rc_subscription_status is updated on the user.

Should purchases go to Iterable as events or as purchases?

Both are available. By default every step is a custom event. Tick Send paid events as Iterable purchases and initial purchases, trial conversions, renewals and one-time purchases with revenue above 0 go to Track Purchase for Iterable's revenue reports. Refunds always go as events with negative revenue.

Which user does Iterable update, the email or the user ID?

Iterable takes one of the two per request. RevenueDot uses the $email attribute when your app set it, else $iterableUserId, else the app user ID as userId.

Is there a RevenueCat Iterable integration alternative?

Yes. RevenueDot follows RevenueCat's Iterable integration: the same rc_*_event names, the rc_subscription_status attribute and the email or user ID rule. Checked October 2026. RevenueDot is open source and free to self-host.

Are sandbox purchases sent to Iterable?

Only when a Sandbox server-side API key is saved, which should belong to a second Iterable project. Without it, sandbox events are skipped and the delivery log says why.

Sources: Iterable · Iterable API documentation · RevenueCat: Iterable integration. Iterable is a trademark of its owner, used to describe compatibility. RevenueDot is not affiliated with or endorsed by it.

Get started

Send Iterable every subscription event.

Start free on RevenueDot Cloud, free up to $10,000 a month in tracked revenue. Integrations are included on every plan.

Already have an account? Sign in · Prefer your own servers? Self-host free