# Customer.io Pricing: Count Profiles, Objects and Messages Correctly

Canonical URL: https://www.martechdevs.com/blog/customer-io-pricing

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

Data Engineer and Co-founder, martechdevs

Published: 2026-08-24

Last updated: 2026-09-22

Customer.io pricing depends on the plan, billable profiles, message volume and optional usage. People and objects both count as profiles, and records used during the billing cycle can count even after deletion. Build your estimate from the data model and billing history before comparing subscription prices. That exposes costs a current contact count can miss.

A B2B application might have 8,000 people, 1,000 customer accounts and 1,500 subscriptions. Its marketing team sees 8,000 contacts. Its messaging platform can see 10,500 profiles. Add a development workspace and the difference grows again.

That is why the useful buying question is how your production data will be represented. If your team is deciding which people, accounts and events should enter messaging, that decision belongs in the [CRM and lifecycle implementation](https://www.martechdevs.com/crm-lifecycle) scope before the first import.

## What are the current public starting prices?

Customer.io lists Essentials from $100 per month with 5,000 profiles, one million monthly emails and two object types. Premium starts at $1,000 per month, billed yearly, with custom profile and email volumes. Enterprise requires a quote. The pricing page lists unlimited user seats; employee count is therefore a poor substitute for a usage estimate. [Customer.io pricing](https://customer.io/pricing).

Those starting points do not make the plans interchangeable. Check the features that determine whether the team can operate the platform, including workspace separation, access controls, support and the required data connections. A lower subscription that requires an engineer to rebuild a missing operating capability may be the more expensive choice.

Use the published rate only for the configuration it describes. Where a quote changes allowances, unit rates or commitments, keep the signed terms alongside the estimate. Do not combine one plan's base fee with another plan's volume rate because both appear somewhere in the documentation.

## Which records belong in the profile count?

Billable profiles include people and objects in every workspace, including development environments. A person stored in two workspaces counts twice. [How Customer.io bills](https://docs.customer.io/accounts/billing/how-we-bill/).

Start with the records the journeys require. A person might receive messages. An account object might provide a shared renewal date. A subscription object might explain which product is renewing. Each can serve a valid purpose, but each needs a reason to exist in the messaging system.

An object type and an object instance are different. “Account” is a type. Each individual account is an instance. A limit of two object types does not mean only two object records can be stored. For the example above, accounts and subscriptions use two types while their 2,500 instances contribute to the profile count.

Avoid modelling every source-system table as a messaging object. A warehouse may hold invoice lines, payment attempts, feature usage and historical plan changes. The lifecycle platform might need only the current subscription state and a small number of events. Decide from the message's eligibility and personalisation requirements rather than the available database schema.

Our guide to a [single customer view](https://www.martechdevs.com/blog/single-customer-view) explains why preserving the relationships matters. Flattening everything into a person's properties can also fail when that person belongs to multiple accounts. Reducing billable records by destroying the meaning of the data is a false saving.

## Why can deleted records still appear on the bill?

Customer.io's high-watermark method includes profiles deleted during the cycle. Recreating one in that cycle adds another billable record; the closing database count therefore cannot explain the invoice alone. [Profile billing](https://docs.customer.io/accounts/billing/how-we-bill/).

Consider this illustrative sequence:

1. The cycle starts with 10,000 billable profiles.
2. An integration adds 2,000 previously uncounted profiles.
3. The team deletes 3,000 old profiles.
4. Another integration recreates 1,000 of the deleted profiles.

After step three, the current database contains 9,000 profiles, while 12,000 have contributed to that cycle's count. After step four, the current database contains 10,000, while the illustrative billable count reaches 13,000. This assumes each addition meets the billing definition and there are no special contractual adjustments.

The mistake is trying to explain the invoice using only a month-end screenshot. Preserve the starting count, additions, deletions, recreations and workspace breakdown. These movements tell you whether the increase came from genuine audience growth, a migration or an integration loop.

If someone proposes a cleanup, ask what will prevent the records from returning. Deleting profiles while leaving an unconditional daily import in place produces churn in the database without solving the source of the cost.

## What would a realistic Essentials estimate look like?

The public pricing page lists additional Essentials profiles at $0.009 each and additional emails at $0.12 per 1,000. Confirm those rates and the allowance on your actual account before using this example. [Published allowances and overages](https://customer.io/pricing).

Assume a small SaaS business needs:

- 8,000 people, 1,000 accounts and 1,500 subscription objects.
- No additional billable profiles in other workspaces or from deletion and recreation during the cycle.
- 1.25 million emails in the cycle.
- Two object types and no requirement that forces a higher plan.
- No separately charged SMS, AI usage, taxes or contractual adjustments.

The estimate is:

```text
Total profiles = 8,000 + 1,000 + 1,500 = 10,500
Profiles above allowance = 10,500 - 5,000 = 5,500
Profile overage = 5,500 × $0.009 = $49.50

Emails above allowance = 1,250,000 - 1,000,000 = 250,000
Email overage = 250 × $0.12 = $30.00

Illustrative monthly platform cost = $100 + $49.50 + $30 = $179.50
```

This is a planning calculation, not a quote. It also shows why a seat-based comparison can mislead. Growing from ten employees to twenty-five does not change this particular calculation. Growing the represented audience, object population or message volume does.

Now stress the model. A migration adds 4,000 otherwise uncounted profiles during the cycle. At the assumed rate, that adds $36 to the profile component even if the team removes them before month-end. A new object type can introduce a separate plan-entitlement question. Both changes should be visible before the migration is approved.

For a fair comparison with an enterprise engagement platform, use the same audience, journeys and channel volumes in the [Braze pricing worksheet](https://www.martechdevs.com/blog/braze-pricing). Different billing units should not hide different workload assumptions.

## Which message costs need their own forecast?

Email billing counts messages reaching the provider, including later bounces or suppressions. Reconcile provider activity, not opens or successful deliveries. [Email billing](https://docs.customer.io/accounts/billing/how-we-bill/).

For operational planning, forecast messages from journey entries and eligibility. A five-step onboarding flow does not necessarily produce five sends per entrant. Customers can exit, miss a condition or become ineligible. Conversely, repeated entry or overlapping campaigns can produce more messages than a simple subscriber multiplier predicts.

SMS requires a separate model. Customer.io's billing documentation distinguishes message segments, inbound replies, multimedia messages and provider-related charges. A long message or different character encoding can require more than one segment. Preview representative copy with the actual sending setup and price the segments, destination mix and replies. [Customer.io SMS billing](https://docs.customer.io/accounts/billing/sms-billing/).

Keep AI usage separate too. Customer.io documents shared account credits for LLM automation actions, with consumption depending on the model and input/output. Additional credits are sold in 100,000-credit increments at $10. A prompt test and a live journey action do not have identical billing treatment. [AI credits](https://docs.customer.io/accounts/billing/ai-credits/).

For an AI step, estimate eligible journey executions first. Then measure representative input and output sizes in a controlled pilot. A long account history attached to every request can change consumption without any increase in customer count. Set a maximum useful context and require the output to serve an actual message or decision.

## Can a monthly email allowance still leave you unable to send?

Yes. Commercial allowance and operational sending limits are different. Customer.io documents daily warmup limits for new Essentials accounts, with increases related to account age and sending health. Reaching the daily limit can stop additional messages even when the monthly allowance has room. [Plan features and sending limits](https://docs.customer.io/accounts/billing/plan-features/).

Build the migration calendar around that distinction. Identify transactional messages that cannot wait, the first campaign's audience and the sequence for introducing other sends. Confirm the account's actual limits before scheduling a launch-day announcement to the entire database.

Warehouse connections also need precise wording. Sending data into the messaging platform and exporting its data to a warehouse are different capabilities. Check the direction, destination and plan entitlement for your required connection. “Integrates with our warehouse” is too vague to sign off.

Our [Customer.io versus Klaviyo comparison](https://www.martechdevs.com/blog/customer-io-vs-klaviyo) is useful when the decision concerns product events versus commerce-centred workflows. Pricing should follow that operating decision, while still exposing the cost of the data model it requires.

## How can you reduce cost without breaking lifecycle messaging?

Begin upstream. Define which records become eligible for the messaging platform and what must remain in the source system. Then document when an object or profile is no longer needed. Customer.io specifically recommends checking integrations that could recreate deleted data and reviewing unnecessary objects. [Reducing billing overages](https://docs.customer.io/accounts/billing/reduce-billing-overages/).

Retention decisions must preserve the records the business still needs. Keep subscription and consent history in the designated system of record, prevent removed contacts from being reintroduced incorrectly, and check whether active journeys depend on an object before removing it. A cheaper invoice is not a successful cleanup if renewal notices lose their account context.

Use this acceptance checklist before the next billing cycle:

## Checklist

- [ ] Reconcile people and objects across every workspace.
- [ ] Explain the difference between current profiles and profiles counted during the cycle.
- [ ] Identify which imports can recreate removed records and change those rules first.
- [ ] Verify object relationships used by active journeys before deletion.
- [ ] Separate email, SMS and AI forecasts, including their own allowances and limits.
- [ ] Confirm required features, contract rates and sending capacity against the planned launch.

![Map profile records and workspace history, forecast usage, verify plan requirements and price the migration peak.](https://www.martechdevs.com/assets/blog/customer-io-pricing.svg)

Give finance the resulting estimate with a named owner for each uncertain input. Audience growth belongs with acquisition planning. Recreated records belong with the integration owner. Journey volume belongs with lifecycle operations. That makes the forecast something the team can manage rather than a number copied from a pricing page.

## Frequently asked questions

### Does Customer.io charge for every employee?

Its public pricing lists unlimited user seats. Estimate the data and messaging workload first, then check whether the team's access-control and support requirements need a different plan. Company headcount can affect those requirements without being the direct billing unit.

### Do account and subscription objects count as profiles?

Yes. Include each required object instance in the estimate, and document the journey it supports. Ask the lifecycle owner to justify unused relationships before copying more warehouse tables into messaging.

### Will deleting profiles reduce this month's invoice?

Do not budget an immediate reduction. Schedule cleanup before the next cycle, repair recreating imports first, and reconcile the next invoice against the saved movement ledger.

### Should we upgrade to Premium to avoid overages?

Compare a written quote against expected and peak usage, required features and operating support. A higher starting commitment is not automatically justified by modest overages. It can still be appropriate when a required entitlement or service makes the lower plan impractical.

### What is the most useful first step before requesting a quote?

Prepare a data model and one cycle's workload forecast. Include people, objects, workspaces, message volumes and migration overlap, then mark which values are observed and which are assumptions. That gives the vendor a specific configuration to price and gives your team a way to evaluate the answer.

## Sources

1. [Customer.io pricing](https://customer.io/pricing). Accessed 22 September 2026.

2. [How Customer.io bills](https://docs.customer.io/accounts/billing/how-we-bill/). Accessed 22 September 2026.

3. [Reducing billing overages](https://docs.customer.io/accounts/billing/reduce-billing-overages/). Accessed 22 September 2026.

4. [Customer.io SMS billing](https://docs.customer.io/accounts/billing/sms-billing/). Accessed 22 September 2026.

5. [Customer.io AI credits](https://docs.customer.io/accounts/billing/ai-credits/). Accessed 22 September 2026.

6. [Plan features and sending limits](https://docs.customer.io/accounts/billing/plan-features/). Accessed 22 September 2026.