Facebook Share Count: Fetching It From the Graph API

One tall stack of layered grey and graphite paper discs beside a small graphite paper key lying flat

Why old plugins show zero

Early share plugins read Facebook counts from the legacy REST API or from Graph requests without a token. Facebook deprecated the REST API for apps on Graph API v2.1 and later, and then began requiring tokens and enforcing rate limits. The old post on this domain announcing that the REST API was deprecated for versions 2.1 and higher collected links because thousands of sites hit this at once. Counters that were never updated still return nothing.

The request today

Ask the Graph API for the URL as an object and request its engagement field. The response contains separate figures for shares, reactions, comments and plugin comments. The exact API version in the path changes over time, so use the current version listed in Facebook's developer documentation.

GET https://graph.facebook.com/{version}/?id={encoded URL}&fields=engagement&access_token={app access token}

{
  "engagement": {
    "reaction_count": 12,
    "comment_count": 3,
    "share_count": 40,
    "comment_plugin_count": 0
  },
  "id": "https://example.com/post/"
}

You need an access token. An app access token, made from your app ID and app secret, is the usual choice for a server-side counter. See creating a Facebook app ID and choosing and creating a Facebook access token.

Field	What it counts	Put it in a "shares" counter?
share_count	Times the URL was shared or posted	Yes
reaction_count	Reactions on posts containing the URL	Only if the counter is labelled engagement
comment_count	Comments on posts containing the URL	Only if the counter is labelled engagement
comment_plugin_count	Comments left through the comments plugin on your page	Usually no

The counts below are invented; the sequence is the one a well-behaved plugin follows. The post lives at https://example.com/post/, was published on a Monday, and the site uses an app access token stored as a constant. The counter should show shares only, and it should never call the API during a page view.

Encode the address
Run the permalink through rawurlencode() so the slashes and query string survive as one id value. An unencoded URL is the usual cause of the "Unsupported get request" error.
Request the engagement field
Call the endpoint above with wp_remote_get() and a 10 second timeout. In our example the response carries share_count 40 for https and, on a second request for the http variant, share_count 7.
Add the variants
Store 47 as the share total for the post, with the time of the request. Keep the four raw fields too, so a later decision to show engagement needs no new calls.
Store it per post
Write the figures to post meta or a transient keyed by post ID. Give the transient a lifetime that matches the refresh schedule below: one hour on day one, twelve hours in the first month.
Display from the cache only
The template reads the stored number. If the cache is empty, show nothing and queue a refresh rather than calling the API inline.

$id  = rawurlencode( get_permalink( $post_id ) );
$url = "https://graph.facebook.com/{$version}/?id={$id}&fields=engagement&access_token={$token}";
$res = wp_remote_get( $url, array( 'timeout' => 10 ) );
if ( is_wp_error( $res ) || 200 !== wp_remote_retrieve_response_code( $res ) ) { return; } // keep the old count
$data   = json_decode( wp_remote_retrieve_body( $res ), true );
$shares = (int) ( $data['engagement']['share_count'] ?? 0 );
set_transient( 'fb_shares_' . $post_id, $shares, 12 * HOUR_IN_SECONDS );

Rate limits and caching

Most shares happen soon after publishing, so refreshing old posts often only burns rate limit.

The Graph API limits how many calls an app can make in a period. A plugin that asks on every page view will hit that limit on a busy site and then receive errors, which many plugins display as zero. Store the count per post with a timestamp and refresh on a schedule that slows as the post ages. In our worked example, a site with 2,000 posts and the schedule above makes roughly 300 calls a day rather than one per page view, which keeps a modest app well inside its allowance as described on the cited rate-limiting page.

Keep the secret secret

An app access token contains your app secret. Keep it on the server, never in page source or JavaScript.
If the secret is ever exposed, reset it in the app dashboard; that invalidates the old token.
Store it in wp-config.php or the plugin's settings, not in a theme file under version control.

What goes wrong

Symptom	Likely cause	Fix
Every post shows 0 after a plugin update	Plugin switched endpoints and needs a token it does not have	Enter an app token; confirm with a manual request
Counts drop by a large fraction overnight	Plugin stopped adding the http variant, or the token was reset	Check both variants; test the token in the debugger
Some posts update, others do not	Rate limit reached mid-run	Slow the schedule for older posts
Error "(#4) Application request limit reached"	Too many calls in the window	Cache longer; refresh in batches
Error "Invalid OAuth access token"	Token truncated, expired or secret reset	Regenerate and paste again without spaces
Count is right in admin, wrong on the page	Page or object cache serving old HTML	Purge caches after the refresh

A related trap is a counter that overwrites a good number with zero when the API returns an error. Keep the previous value on any non-200 response, as the snippet above does, and log the error instead. The wider fix order lives in share counts not updating, and the definitions behind the fields are in how share counts work.

Check it worked

Make one manual request for a post you know has been shared and confirm share_count is above zero.
Confirm your counter shows that share_count, or the sum for the variants you asked for, and nothing larger.
Load the post ten times in a row and check your server log: there should be no calls to graph.facebook.com during page views.
Search the rendered page source for your app secret. It must not appear.
Come back after one refresh interval and confirm the stored timestamp moved.

This guide belongs to the share counts section. If you are working through the same setup, tracking shares and pageviews in analytics and how share counts work, and why most networks stopped are the usual next questions.

Sources

Questions

Why is my Facebook share count zero?

Usually the plugin uses an old endpoint, has no valid token, or has been rate limited. Check the token and the plugin's last update date.

Do I need an access token for Facebook share counts?

Yes. Current Graph API requests for URL engagement need a token; an app access token works for server-side counters.

Does the share count include reactions?

The API returns reactions separately. Whether they are added into one number depends on your plugin.

How many Graph API calls can a share plugin make?

The allowance is set per app and per period, as described on the cited rate-limiting page, and it changes. A schedule that refreshes new posts hourly and old ones weekly stays far below it on most sites.

Can I get a Facebook share count without an app?

Not reliably. Token-free requests to the URL node stopped working years ago, so any plugin that still shows counts either has an app token or reads a third-party estimate.

Hannah Voss, Editor. Checks every guide against a working WordPress install and the networks' current documentation. Last reviewed September 2026.

About the editor and our methods

Why old plugins show zero

The request today

Facebook share count worked example in WordPress

Encode the address

Request the engagement field

Add the variants

Store it per post

Display from the cache only