Throttling guidelines
Background
NGP VAN builds and maintains CRM platforms that power campaigns and organizations of all sizes, and in collaboration with large, distributed clients and integration partners. (Outside of the political market, NGP VAN products are branded as EveryAction.) While NGP VAN does not own any voter or client data, we play a key role in helping campaigns and vendors integrate securely, efficiently, and at scale.
As a developer, it’s important to understand how these platforms are structured and how your integration interacts with them. The voter data in VAN may be managed differently than person level data you’ve worked with, so don’t hesitate to reach out to [email protected] with any questions.
The client platforms and NGP VAN API support team are shared resources across a broad ecosystem of campaigns and partners. During high volume periods like Get Out The Vote (GOTV), database usage and support tickets increase exponentially. Our goal is to ensure that every integration can sync data quickly and reliably, but it’s equally important for developers to use these shared resources responsibly to keep data flowing smoothly across the ecosystem.
As of November 2025, we have launched updates to API access – including clearer policies, refined rate management, and a dedicated partnership program – to help integrations perform smoothly and scale with growing demand throughout the cycle.
Rate Limit Requirements
Our APIs are tuned for expected usage patterns, with some endpoints optimized for high-frequency operations and others designed for bulk or asynchronous data processing. Rate limits vary depending on the type of integration and partnership tier.
We maintain two rate categories:
- Vendors who participate in our API Partnership Program.
- Custom integrations built by clients for their own use.
These tiers ensure stability across our shared infrastructure while giving high-volume partners room to scale.
Vendor: API Partnership Program
Tier | Key Limits | Request Levels (per key) | Monthly API Requests |
|---|---|---|---|
Startup | 1 Sandbox, up to 5 Production | High: 10 rps | 1M |
Standard | Unlimited Production | High: 50 rps | 50M |
Preferred | Unlimited Production | High: 200 rps | Unlimited |
To explore upgraded limits or partnership benefits, reach out to [email protected].
Clients: Custom Integrations
Tier | Key Limits | Request Levels (per key) | Monthly API Requests |
|---|---|---|---|
Custom | Keys limited to a single client. | High: 200 rps | 30M |
To explore upgraded limits or partnership benefits, reach out to [email protected].
Endpoint Rate Categories
Each API endpoint is assigned a rate category — High, Medium, or Low — based on its typical data volume and processing cost. These categories determine how many requests per second (rps) are allowed under your integration tier.
High-throughput endpoints
Designed for rapid, transaction update such as canvassing data.
- POST /people/{vanId}/canvassResponses
- POST /people/{personIdType}:{personId}/canvassResponses
Low- throughput endpoints
Used for matching or bulk imports that require heavier processing or background jobs
- POST /people/find
- POST /people/findOrCreate
- POST /bulkImportJobs
- GET /bulkImportJobs/{jobId}
- GET /bulkImportJobs/resources
- GET /bulkImportMappingTypes
- GET /bulkImportMappingTypes/{mappingTypeName}
- GET /bulkImportMappingTypes/{mappingTypeName}/{fieldName}/values
Medium-throughput endpoints:
All other endpoints not listed above.
Implementation Best Practices
Error Handling & Replay Logic
- Design for retries: Your application should be able to replay API calls automatically when transient errors or rate limits occur.
- Fallback options: If automated retries aren’t possible, provide a contingency workflow (for example, a CSV upload through the VAN user interface).
- This ensures that data integrity is maintained even during high-volume periods like GOTV.
Data Integrity for Phone and SMS Apps
- When syncing disposition data (e.g., wrong number, disconnected, opt-in status), use the phoneId field to ensure updates are correctly associated.
- Example:
{
"canvassContext": {
...
"phoneId": 867
}
More information is available in the API documentation section here.
Performance Optimization
- Run test or “dry run” syncs with NGP VAN prior to high-volume events such as GOTV or EOQ.
- Contact [email protected] for recommendations on optimizing request patterns or batching operations.
Data Corrections & Support
- If data is synced incorrectly and requires backend remediation, the client must contact NGP VAN support directly.
- Vendors cannot request database rollbacks or edits on behalf of clients.
- Include specific examples and record IDs when submitting support requests to speed resolution.
Collaboration & Communication
- Reach out proactively if you anticipate unusual traffic or integration behavior that could affect shared system performance.
- The API support team can assist with scaling strategies, error analysis, and rate management.
Previous Throttling Guidelines
Click this arrow to expand previous throttling guidelines.
These are the throttling guidelines for both vendor and client integrations before November 17th, 2025.
Suggested throttling
No more than 3 concurrent requests per API key/client, throttled by duration.
Though this is considered a more “advanced” method of throttling and meant for high volume vendors specifically it can be used by vendors of any size. In general, a partner should be able to rely on the actual duration of each API call as a reasonable proxy of how fast they can operate. So if a partner limits their total number of concurrent requests it will ‘automatically’ adjust for the difference in API calls they are using.
Three concurrent workers can get through 60 requests/sec for something that takes 50ms (like post canvass results) but closer to 6 requests/sec for something that takes 500ms (like match and store person). And if the system is under pressure, a high volume integration that is set up this way will reduce their load on us automatically. If for some reason a single client requires more than one API key for the same vendor, the limitation should be applied across all of those keys.
Assuming normal database utilization, if a partner was using this method of throttling across 50 states, they could post canvass results for more than 85 million records in a 24 hour period.
"Simple" per second throttling
No more than 2 calls per second per API key for /findOrCreate and no more than 5 calls per second for other endpoints.
These are safe numbers for essentially every standard use case and it’s generally fine for developers to bump from 5 calls per second to 10, with the exclusion of match and store person endpoints such as findOrCreate which are more intensive. We may ask a specific developer to throttle back down to 5 during a high volume period.
Updated 5 months ago
