Default Service Limits

mParticle imposes certain limits on incoming data in order to protect the performance of both the mParticle dashboard and your apps. This includes limits around the length of individual data points, such as event names, how fast mParticle can receive data, and how many unique data points a workspace or account can have.

The tables below list mParticle’s Default Limits. Enterprise customers should contact their Customer Success Manager for custom limits.

mParticle can receive data across many channels, and limits are not always enforced in the same way for each channel. Where appropriate, the details section of each table describes how limits affect SDK data - received from mParticle’s native SDKs - and S2S or ‘server-to-server’ data. S2S data includes data received via the Events API, and from partner feeds.

Incoming event batches

The following limits apply to event batches being ingested.

Resource
Limits Details
Event name length 256 characters SDK logs an error and the event is not uploaded. For S2S data, names exceeding the limit is truncated.
Event attribute name length 256 characters SDK logs an error and no attributes are set for the event. S2S truncates the attribute name.
Event attribute value length 4096 characters SDK logs an error and no attributes are set for the event.
User attributes per event batch 100 SDK allows only 100 attributes per user and logs an error if you attempt to create additional attributes.
User attribute name length 256 characters SDK logs an error and no attributes are set.
User attribute value length 4096 characters SDK logs an error and no attributes are set.
User attribute list 1000 Entries SDK logs an error and no attributes are set.
User attribute list entry length 512 characters SDK logs an error and no attributes are set.

SDK event data

The following limit applies only to data being ingested with an SDK.

Resource
Limits Details
Total batch size 128KB If this limit is exceeded, the SDK automatically attempts to break up the batch into multiple smaller batches.

Events per workspace and user

The following limits apply to events per workspace or user.

Resource
Limits Details
Unique event names and Screen Names per workspace 1000 New unique event names over the limit are dropped from incoming data. You can request this limit be raised, but proliferating unique event names usually indicate problems with your data and can impact performance of both the mParticle dashboard and your apps. Therefore, the limit won’t be raised except where absolutely necessary.
Average events per user within 24 hours 150 This limit can be raised by request.
Average events per user within 30 days 175 This limit can be raised by request.

mParticle reserves the right to restrict average events per user to ensure platform quality of service.

Events API

The following limits apply to resources in the Events API.

Resource
Limits Details
Batches per second Variable but defaults to 270 batches per second If exceeded, the Events API returns a 429 HTTP response code. Learn more about how the Events API is throttled in API Throttling.
Total Request Size 256kb Whether using the /events or /bulkevents endpoint, the total request size must be under 256kb regardless of how many batches are included in the request.

Profile API

The following limit applies to resources in the Profile API.

Resource
Limits Details
Requests per second Variable but starting at 15 requests per second Actual limits scale up and down with demand. If you exceed the limit, the mParticle API returns an HTTP 429 response code. Set up your implementation to respect 429 responses and retry the request in an exponential backoff pattern.

Data storage

The following limits are explained in detail in Data Retention.

Resource
Limits Details
Event batch long-term archival storage 24 months Contact your mParticle Customer Service representative if you need longer or shorter archival storage.
Profile storage 30 days User Profiles are deleted after 30 days of inactivity.
Real-time audience storage 30MB Maximum size of a single users data in real-time audience storage. Typical users are ~200kb.

Data Subject Request API

The following limits apply to resources in the Data Subject Request API.

Resource
Limits Details
Requests per minute 1000 requests per minute This limit applies across three API actions (GET, POST, and DELETE) and is enforced per Workspace
Total new requests 80,000 requests per day This limit applies to the POST API action and is enforced per Workspace

Data plans

The following limits apply to resources used in data planning.

  • Similar to our event limit for workspaces, data plans support up to 1,000 data points.
  • You can upload data plan JSON files smaller than 10 MB.
  • Managing plans with more than 400 data points in the UI becomes unwieldy. Manage plans outside of the UI for larger plans. For more information, see the Data Planning API guide.
  • You can block data only for unplanned violations: events and attributes with names that diverge from the schema defined in a data plan.

Data Planning API

The following limits apply to resources in the Data Planning API.

Resource
Limits Details
Requests per minute per account 3000 requests per minute This limit applies to all GET, POST, and PATCH API actions.
Requests per minute per organization 6000 requests per minute This limit applies to all GET, POST, and PATCH API actions.

Warehouse Sync API

The following limits apply to resources in the Warehouse Sync API.

Limit
Value Notes
Max number of Active Pipelines 5
Catchup limit for new hourly pipeline 7 days
Catchup limit for new daily pipeline 6 months
Catchup limit for new weekly pipeline 3 years
Catchup limit for new monthly pipeline 5 years
Record count limit per hourly interval 1 million
Record count limit per daily interval 24 million
Record count limit per weekly interval 40 million
Record count limit per monthly interval 40 million
Record count limit per once request 40 million
Record count limit per on-demand request 24 million This request must be used with an on-demand trigger.

Workspaces, users, and name length

The following limits apply to workspaces, users, and the name length limits for audiences and tags.

Resource
Limit Details
Workspaces 50 Users are prevented from creating additional workspaces. This limit can be raised by arrangement.
Users 200 Admins are prevented from creating additional users. This limit can be raised by arrangement.
Audience name Length 100 Audience name and external name fields are limited to 100 characters.
Tag name length 18 Tag names are limited to 18 characters.

API throttling

mParticle APIs have two types of rate limits in place to protect mParticle’s servers from high demand:

  • Speed: limits the rate of traffic.
  • Acceleration: limits the rate of increase of traffic.

You can configure your mParticle integration to respond programmatically to prevent data loss according to the 429 response header you receive.

Throttled resources include a percentage representation of your current total usage in 2xx response headers. These percentage-used headers allow you to modify your request speed or acceleration to prevent exceeding a rate limit.

429 rate limit exceeded

An API request that exceeds the rate (speed) limit of a resource receives a 429 response and a header with the format:

X-mp-rate-limit-exceeded: "LIMIT"

where "LIMIT" is the ID of the source of the limit as described in the table below:

Value Description
"org" A limit applied to an entire organization.
"account" A limit applied to an account ID within a parent organization.
"app" A limit applied to an app ID within a parent organization.
"feed" A limit applied to a feed ID within a parent organization.
"workspace" A limit applied to a workspace ID within a parent organization.
"acceleration" An acceleration limit that can be applied to any of the speed limits listed above.

An API request that exceeds any applicable acceleration limit receives a 429 response and a header with the format:

X-mp-rate-limit-exceeded: “acceleration”

2xx percentage used

Rate limited endpoints return an X-mp-rate-limit-percentage-used header with 2xx responses including the percentage of the limit used. If a resource has multiple limits, the response header includes the greatest consumption percentage of all applicable speed and acceleration limits, omitting any user-based limits.

For example, if a request is not throttled and is subject to both a speed and acceleration limit, and the current consumption is 92% of the speed limit and 50% of the acceleration limit, then the header lists the consumption of the speed limit because it is higher than the current acceleration limit usage:

X-mp-rate-limit-percentage-used: 92

If you receive a 429 response for exceeding a speed limit, reduce the frequency of your requests. Use exponential back-off with jitter and respect the RetryAfter value which is a non-negative decimal integer indicating the number of seconds to delay your request.

If you receive a 429 response for exceeding an acceleration limit, you can still submit requests but you should slow the increase of your request speed. Use exponential back-off with jitter when determining the new frequency of your requests.

Was this page helpful?