At F8 this year, we announced improvements to the way Page management apps are rate limited; these changes take effect on July 11, 2016. Below is more detail around what these updates are.

What is changing?

Today, all apps are rate limited based on daily active people (DAP) - the higher your app's DAP, the higher the rate limit threshold. This model creates problems for Page management apps where DAP is often comprised of only a few Page admins, resulting in frequent rate limiting.

Starting July 11, 2016, calls made to the Pages API using Page access tokens will be rate limited on the Page level, as opposed to on the app level. This means that each Page has a dedicated quota that is shared across all apps using the Page's access token. Nothing will change for apps making calls with user access tokens where app level rate limits apply, nor for apps making calls to the Marketing API where Marketing API rate limits apply.

These changes mean apps that manage Pages will be rate limited less often. We encourage all Page management apps to start using Page access tokens to take advantage of this.

How will Page rate limiting work?

The Page level rate limits will follow a 24-hour sliding window vs. the 1-hour one for app-level rate limiting, with the limit being 4,800 calls per engaged user per 24 hours for any given Page. We will also track CPU time and total time used by the calls.

A Page management app will remain rate limited for as long as its usage in the current 24-hour window exceeds the Page's allowed limit. Any calls made to the Pages API during this phase will receive Error Code 32 and also count towards subsequent limit calculations. Calls made by an app using access tokens of other Pages will remain unaffected, which is different from app level rate limiting where the app would be blocked from making any more calls.

How are daily engaged users calculated?

This is the unique number of people who have engaged with a Page in a 24-hour period. Engagement includes a click on the Page or Page content. You can get this value with the Insights APIpage_engaged_users metric. We use the number of engaged users in the previous 24 hours to calculate the rate limits for the current 24-hour window.

What new tools are available?

1. New HTTP Header includes rate limit information

Starting today, with every request made using a Page access token, the response will include a header X-Page-Usage specifying what percentage of the Page's quota has been utilized. There is no header if the Page's utilization is effectively 0%. If your app has non-zero usage for app level rate limits you may see both X-Page-Usage and X-App-Usage headers in a single response. The values for call_count, total_cputime and total_time are whole numbers representing the percentage used values for each of the metrics. When any of these metrics exceed 100, the app will be rate limited. Please note that while this is live today, the Page level rate limits will not take effect until July 11, 2016.

Example of page utilization header:

X-Page-Usage : {'call_count' : 85, 'total_cputime' : 56, 'total_time' : 60}

2. Graph for apps showing usage of Pages they manage

Starting July 11, 2016, if your app is calling the Pages API with the Page's access token, you will see stats in your app dashboard that shows each Page's usage towards the rate limits.

We will publish these new Page level rate limits on our developer documentation by July 11, 2016.

We think these changes and tools will help apps manage Pages and serve their customers more effectively. As always, we welcome your feedback in our developer community group.