Browse Docs Request a Rate Limit Increase

Overview

Procore’s default rate limits fit most integrations. If your app has outgrown them, you can request a higher limit for that app.

Increases are granted per app and are based on demonstrated production usage. The API Review Board evaluates every request against your app’s actual traffic from the past 30 days.

An increase raises your ceiling. It does not change the behavior that reached the old one. An app generating a high volume of 403 or other client errors is not fixed by more quota — the underlying problem goes unaddressed, and a higher ceiling lets it run further before anything surfaces. Resolve the behavior first, or an increase makes the situation worse rather than better.

Optimize before you apply. Requests built on an already-efficient call pattern review faster and are approved more often. See Rate Limiting.

Before you apply

Work through the efficiency practices in Rate Limiting first — index endpoints, caching, and reduced polling.

Then review both of the following, because they answer different questions:

• Integration Health tells you whether Procore has flagged your app against platform best practices, and what to fix.
• API Call Activity Report shows the underlying detail — which endpoints drive your volume and where your errors are concentrated.

If Integration Health flags errors, especially 4xx responses, resolve those first. They weaken the case for an increase, and they will still be there afterward.

Failed calls consume your quota. A 400, 403, or 404 counts against your limit exactly like a successful call, so reducing your error rate recovers capacity directly. See Rate Limiting.

Consider whether more quota is the right fix

Some workloads are better served by a different approach. These are worth evaluating before you apply, and in some cases they remove the need for an increase entirely.

Confirm which limit you are actually hitting. Procore enforces an hourly limit and a spike limit measured over a 10-second window. Only the hourly limit is requestable — the spike limit is set by Procore and adjusts alongside it. If your traffic fits within the hour but arrives in bursts, you are hitting the spike limit, and more hourly quota will not help. Pace your calls across the window instead. See Rate Limiting.

Combine less frequent polling with webhooks. Apps that poll unchanged data on a short interval spend most of their quota confirming that nothing happened. Subscribe to webhooks so changes reach you as they occur, and keep polling as a reconciliation pass on a longer interval rather than as your primary change-detection mechanism. The two together cost far less quota than frequent polling alone, and you keep a safety net for any event you miss. See How Webhooks Work.

Point reporting and warehouse loads at Procore Analytics. The REST API is transactional — it is built for reading and writing records as work happens, not for bulk extraction. If the goal is hydrating a data warehouse or a business intelligence tool, Procore Analytics is designed for that workload and does not consume your API quota.

Procore Analytics is licensed at the company level. If you are building an integration for your own company, check with your Procore administrator or account team about whether it is already available to you. If you are building on behalf of a customer, raise it with that company. See Getting Started with Procore Analytics.

What we review

Every signal below comes from your app’s own production traffic over the past 30 days.

Requests we typically decline

We rarely approve an increase in these cases:

• No production activity behind an ongoing request. We size ongoing limits against real traffic, so an app with no production API calls has nothing to size against. Run the app in production first, then apply. Time-boxed work is the exception — see Temporary increases.
• No backoff after a 429. An app that keeps sending at the same or higher rate after being throttled is declined. Add backoff logic first. See Rate Limiting.
• A high non-429 client error rate. Frequent 400, 403, or 422 responses signal unresolved integration issues, and they are already spending the quota you want more of. Resolve those before requesting more capacity.
• Volume driven by patterns a different approach would solve. Polling that webhooks could replace, per-record calls that an index endpoint could batch, or bulk extraction better served by Procore Analytics. We will point you to the alternative rather than raise a limit the workload should not need.
• Anticipated volume with nothing live behind it. Apply once the traffic exists rather than ahead of a projected rollout.

A declined request is not final. Reapply once the underlying issue is resolved and your traffic shows it.

How to apply

1. Confirm your app is running in production and generating consistent traffic.
2. Review your Integration Health status, then download your API Call Activity Report to investigate further.
3. Submit the API Rate Limit Increase Request form.

The form explains what each field needs. Two values are worth locating before you start, because neither is in front of you when you open it:

• Developer App URL — your request cannot be reviewed without it. Log in to the Developer Portal, open My Apps, and select your app, then copy the URL from your browser address bar.
• Company ID — the Procore company submitting the request. Retrieve it from the List Companies endpoint.
  
  

Temporary increases

Some work needs headroom for a defined period rather than permanently — a data migration, an archival job, or a one-time backfill. Give an end date on the form rather than requesting an ongoing increase.

A temporary increase is granted with an agreed revert date. On that date your app returns to its previous limit, so plan the work to finish inside the window.

Keeping your increase

Inactive apps lose their increase, without advance notice. An app that records zero production API calls for a full calendar month returns to the default limits.

We review approved increases for continued use. Removing headroom from dormant apps keeps capacity available for integrations that are actively using it.

Because there is no advance notification, treat the X-Rate-Limit-* response headers as the source of truth for your current limit. An app returning from a dormant period should read them before resuming heavy traffic. See Rate Limiting.

Removal is not permanent. If your app becomes active again, apply through the same form and reference the previous increase.

Next steps

• Rate Limiting — headers, 429 handling, and efficiency practices.
• Integration Health — the status we review with your request.
• API Call Activity Report — the 30-day CSV that shows what drives your volume.
  
  

Need Help?

We’re here to support you at every step of your journey. Here’s how to get help:

You can also explore our learning tools and support resources in the Help & Learning Center.