Match customer IDs across billing and product events

Choose one external ID for each customer

Use a stable identifier that your backend can provide across events and customer records. Churnor does not merge records just because their email addresses match. Keep the identifier in a consistent format and avoid switching between an internal database ID and a billing-provider ID without an explicit mapping.

How each source identifies a customer

• Events API: send customer_id or user_id. If both are present, customer_id is used.
• CSV: map your customer or user ID column to the required Customer / User ID field.
• Stripe: the Stripe customer ID is used as the external ID. The connector does not map an application ID or merge by email.
• Paddle: the Paddle customer ID is used by default. To match an existing external ID, set churnor_customer_id in subscription custom_data before connecting and importing.
• Dodo Payments: the Dodo customer ID is used by default. To match an existing external ID, set churnor_customer_id in subscription metadata before connecting and importing.

For Paddle and Dodo, use the same mapped value across that customer’s subscriptions. This is an external identifier, not Churnor’s internal record ID.

Plan identity before sending data

1. Choose the customer ID your application treats as canonical.
2. Map that ID in CSV imports and use it in Events API requests.
3. For Paddle or Dodo, add the supported custom ID field before connecting if the provider ID differs.
4. For Stripe, use its customer ID consistently for events, CSV, and billing records.
5. Review a customer record and its activity after sending a test event.

Read the source-specific setup guides

CSV customer import · Stripe · Paddle · Dodo Payments

For details about payload fields and request handling, see the Events API documentation.