Data Subject Request API Version 1 and 2
Data Subject Request API Version 3
Platform API Overview
Accounts
Apps
Audiences
Calculated Attributes
Data Points
Feeds
Field Transformations
Services
Users
Workspaces
Warehouse Sync API Overview
Warehouse Sync API Tutorial
Warehouse Sync API Reference
Data Mapping
Warehouse Sync SQL Reference
Warehouse Sync Troubleshooting Guide
ComposeID
Warehouse Sync API v2 Migration
Bulk Profile Deletion API Reference
Calculated Attributes Seeding API
Data Planning API
Custom Access Roles API
Group Identity API Reference
Pixel Service
Profile API
Events API
mParticle JSON Schema Reference
IDSync
AMP SDK
Initialization
Configuration
Network Security Configuration
Event Tracking
User Attributes
IDSync
Screen Events
Commerce Events
Location Tracking
Media
Kits
Application State and Session Management
Data Privacy Controls
Error Tracking
Opt Out
Push Notifications
WebView Integration
Logger
Preventing Blocked HTTP Traffic with CNAME
Linting Data Plans
Troubleshooting the Android SDK
API Reference
Upgrade to Version 5
Cordova Plugin
Identity
Direct URL Routing FAQ
Web
Android
iOS
Initialization
Configuration
Event Tracking
User Attributes
IDSync
Screen Tracking
Commerce Events
Location Tracking
Media
Kits
Application State and Session Management
Data Privacy Controls
Error Tracking
Opt Out
Push Notifications
Webview Integration
Upload Frequency
App Extensions
Preventing Blocked HTTP Traffic with CNAME
Linting Data Plans
Troubleshooting iOS SDK
Social Networks
iOS 14 Guide
iOS 15 FAQ
iOS 16 FAQ
iOS 17 FAQ
iOS 18 FAQ
API Reference
Upgrade to Version 7
Getting Started
Identity
Upload Frequency
Getting Started
Opt Out
Initialize the SDK
Event Tracking
Commerce Tracking
Error Tracking
Screen Tracking
Identity
Location Tracking
Session Management
Initialization
Content Security Policy
Configuration
Event Tracking
User Attributes
IDSync
Page View Tracking
Commerce Events
Location Tracking
Media
Kits
Application State and Session Management
Data Privacy Controls
Error Tracking
Opt Out
Custom Logger
Persistence
Native Web Views
Self-Hosting
Multiple Instances
Web SDK via Google Tag Manager
Preventing Blocked HTTP Traffic with CNAME
Facebook Instant Articles
Troubleshooting the Web SDK
Browser Compatibility
Linting Data Plans
API Reference
Upgrade to Version 2 of the SDK
Getting Started
Identity
Web
Alexa
Overview
Step 1. Create an input
Step 2. Verify your input
Step 3. Set up your output
Step 4. Create a connection
Step 5. Verify your connection
Step 6. Track events
Step 7. Track user data
Step 8. Create a data plan
Step 9. Test your local app
Overview
Step 1. Create an input
Step 2. Verify your input
Step 3. Set up your output
Step 4. Create a connection
Step 5. Verify your connection
Step 6. Track events
Step 7. Track user data
Step 8. Create a data plan
Overview
Step 1. Create an input
Step 2. Verify your input
Step 3. Set up your output
Step 4. Create a connection
Step 5. Verify your connection
Step 6. Track events
Step 7. Track user data
Step 8. Create a data plan
Step 1. Create an input
Step 2. Create an output
Step 3. Verify output
Node SDK
Go SDK
Python SDK
Ruby SDK
Java SDK
Introduction
Outbound Integrations
Firehose Java SDK
Inbound Integrations
Compose ID
Glossary
Data Hosting Locations
Migrate from Segment to mParticle
Migrate from Segment to Client-side mParticle
Migrate from Segment to Server-side mParticle
Segment-to-mParticle Migration Reference
Rules Developer Guide
API Credential Management
The Developer's Guided Journey to mParticle
Create an Input
Start capturing data
Connect an Event Output
Create an Audience
Connect an Audience Output
Transform and Enhance Your Data
The new mParticle Experience
The Overview Map
Introduction
Data Retention
Connections
Activity
Live Stream
Data Filter
Rules
Tiered Events
mParticle Users and Roles
Analytics Free Trial
Troubleshooting mParticle
Usage metering for value-based pricing (VBP)
Introduction
Sync and Activate Analytics User Segments in mParticle
User Segment Activation
Welcome Page Announcements
Project Settings
Roles and Teammates
Organization Settings
Global Project Filters
Portfolio Analytics
Analytics Data Manager Overview
Events
Event Properties
User Properties
Revenue Mapping
Export Data
UTM Guide
Data Dictionary
Query Builder Overview
Modify Filters With And/Or Clauses
Query-time Sampling
Query Notes
Filter Where Clauses
Event vs. User Properties
Group By Clauses
Annotations
Cross-tool Compatibility
Apply All for Filter Where Clauses
Date Range and Time Settings Overview
Understanding the Screen View Event
Analyses Introduction
Getting Started
Visualization Options
For Clauses
Date Range and Time Settings
Calculator
Numerical Settings
Assisted Analysis
Properties Explorer
Frequency in Segmentation
Trends in Segmentation
Did [not] Perform Clauses
Cumulative vs. Non-Cumulative Analysis in Segmentation
Total Count of vs. Users Who Performed
Save Your Segmentation Analysis
Export Results in Segmentation
Explore Users from Segmentation
Getting Started with Funnels
Group By Settings
Conversion Window
Tracking Properties
Date Range and Time Settings
Visualization Options
Interpreting a Funnel Analysis
Group By
Filters
Conversion over Time
Conversion Order
Trends
Funnel Direction
Multi-path Funnels
Analyze as Cohort from Funnel
Save a Funnel Analysis
Explore Users from a Funnel
Export Results from a Funnel
Saved Analyses
Manage Analyses in Dashboards
Dashboards––Getting Started
Manage Dashboards
Dashboard Filters
Organize Dashboards
Scheduled Reports
Favorites
Time and Interval Settings in Dashboards
Query Notes in Dashboards
User Aliasing
The Demo Environment
Keyboard Shortcuts
Analytics for Marketers
Analytics for Product Managers
Compare Conversion Across Acquisition Sources
Analyze Product Feature Usage
Identify Points of User Friction
Time-based Subscription Analysis
Dashboard Tips and Tricks
Understand Product Stickiness
Optimize User Flow with A/B Testing
User Segments
IDSync Overview
Use Cases for IDSync
Components of IDSync
Store and Organize User Data
Identify Users
Default IDSync Configuration
Profile Conversion Strategy
Profile Link Strategy
Profile Isolation Strategy
Best Match Strategy
Aliasing
Overview
Create and Manage Group Definitions
Introduction
Catalog
Live Stream
Data Plans
Blocked Data Backfill Guide
Predictive Attributes Overview
Create Predictive Attributes
Assess and Troubleshoot Predictions
Use Predictive Attributes in Campaigns
Predictive Audiences Overview
Using Predictive Audiences
Introduction
Profiles
Warehouse Sync
Data Privacy Controls
Data Subject Requests
Default Service Limits
Feeds
Cross-Account Audience Sharing
Approved Sub-Processors
Import Data with CSV Files
CSV File Reference
Glossary
Video Index
Single Sign-On (SSO)
Setup Examples
Introduction
Introduction
Introduction
Rudderstack
Google Tag Manager
Segment
Advanced Data Warehouse Settings
AWS Kinesis (Snowplow)
AWS Redshift (Define Your Own Schema)
AWS S3 Integration (Define Your Own Schema)
AWS S3 (Snowplow Schema)
BigQuery (Snowplow Schema)
BigQuery Firebase Schema
BigQuery (Define Your Own Schema)
GCP BigQuery Export
Snowflake (Snowplow Schema)
Snowplow Schema Overview
Snowflake (Define Your Own Schema)
Aliasing
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.
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. |
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. |
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.
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. |
The following limits apply to resources in the Platform API.
| Resource | Limits | Details |
|---|---|---|
| Data points per filter update | 500 | Actual limits scale up and down with demand. If you exceed this limit, the mParticle API could take more than 30s to respond, or time out. Set up your implementation to respect 504 responses and retry your request with smaller batches. Alternatively, you can use the UI as outlined in this guide. |
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. |
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. |
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. It is split into sliding intervals of 8 hours, meaning that a maximum of 26,666 requests are allowed in any 8 hour window. |
The following limits apply to resources used in data planning.
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. |
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. |
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. |
mParticle APIs have two types of rate limits in place to protect mParticle’s servers from high demand:
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.
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. |
"system" |
A limit applied at an mParticle system level across multiple organizations. |
"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”
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?