Why Instagram Play Counts Can Be Missing From an API Response

If you ask for an Instagram profile’s posts, getting the posts back does not always mean getting their play counts too.

That is a frustrating distinction when the counts are the reason you made the request. This post explains what can be missing, why the API can still return a successful response, and how to tell us that you would rather get an error than pay for a response without the counts you need.

What we found in a real missing-count report

On October 22, 2026, we checked five reported profiles. Their first pages contained 51 distinct videos. The production responses were missing play counts for 45 of them, including 38 videos that were not pinned. Two of the affected profiles had no pinned videos in the sample at all.

We then checked the exact same post IDs against Instagram’s public Reels source. It returned play counts for all 51 videos. The numbers were available; our normal posts responses had not recovered them.

Our investigation reproduced a count-lookup problem: a large Reels request could exhaust its short request budget, leaving the post data available but the counts missing. We could reproduce that failure mechanism, though we did not have an internal trace proving that every affected production request failed at exactly the same step.

There was also a separate older pinned video that needed a deeper Reels page. That is why “it must be pinned posts” and “Instagram stopped providing counts” are both too broad as explanations. Some gaps need a retrieval fix on our side. Others can remain unavailable within a bounded request, and customers need a clear way to choose what happens then.

Why posts and counts can arrive separately

We retrieve public Instagram data without signing into the creator’s account. The post list and the source that supplies its play counts do not always return the same information.

A post can have its caption, publication date, media URL, likes and comments available while its play count is unavailable. Our scraper makes bounded attempts to recover missing counts from Instagram and matches those counts to the exact post. If that lookup does not return a usable count, we cannot honestly turn another number into the missing play count.

There are different situations to keep separate:

• An older post can appear near the top of a profile because it is pinned. That does not mean it will also appear in a limited recent Reels lookup. A pin is a possible reason for an individual gap, not proof that every missing count is caused by pinned posts.
• A failed or incomplete count lookup can leave several videos without counts in the same response, even though the posts themselves were retrieved.
• A count can be available on one request and unavailable on the next. A later successful attempt does not make the earlier incomplete response useful for a counts-only workflow.

These are retrieval limits, not evidence that a video has no plays. A missing field or a null value means the count was not available in that response. A numeric 0 means a count of zero. Your application should not treat them as the same thing.

What a successful response means

By default, Instagram posts and user Reels can return usable media even if some play counts are missing. This lets applications that need media or other available data keep working.

That default response is billable at the endpoint’s normal credit cost. Repeating a request without changing this behavior can result in more billable responses that still do not have every count.

An HTTP 200 is not a promise that every optional metric is present. Check the fields your application actually needs, along with the response’s success and error information.

We do not want you to discover that distinction after paying for repeated requests. If counts are a requirement, use the option below rather than relying on the default behavior.

Require play counts when your workflow needs them

Add require_play_counts=true to /v2/instagram/user/posts or /v1/instagram/user/reels. Only the literal query value true enables the check.

For posts:

curl --get 'https://api.scrapecreators.com/v2/instagram/user/posts' \
  --header "x-api-key: $SCRAPECREATORS_API_KEY" \
  --data-urlencode 'handle=example' \
  --data-urlencode 'require_play_counts=true' \
  --data-urlencode 'trim=true'

For user Reels, you can provide a handle or user_id:

curl --get 'https://api.scrapecreators.com/v1/instagram/user/reels' \
  --header "x-api-key: $SCRAPECREATORS_API_KEY" \
  --data-urlencode 'handle=example' \
  --data-urlencode 'require_play_counts=true' \
  --data-urlencode 'trim=true'

With this option enabled:

• Every returned top-level video or Reel must have a valid, non-negative play_count. Zero is valid. On the posts endpoint, photos and non-Reel carousels are exempt, even when a carousel contains video children. On the Reels endpoint, every returned Reel is checked.
• If a required play count is unavailable, the request returns HTTP 503 without deducting credits instead of a successful partial response.
• If the counts are present, the response keeps the usual fields and costs the usual number of credits. The option does not add a surcharge.

The check does not change either endpoint’s response format. A missing, null, negative or non-finite count does not pass.

The check applies to the page being returned. It does not fetch every post or Reel on the account or promise that later pages will have counts. Include require_play_counts=true on every page where you need the check. If you also use trim=true, repeat it on every page to keep the same response format:

• Posts: pass the returned next_max_id as next_max_id. Counts are in items[].play_count.
• Reels: pass the returned max_id as max_id. Full responses have counts in items[].media.play_count; with trim=true, they are in items[].play_count.

You can use require_play_counts=true with or without trim=true. Omit require_play_counts, or set it to false, to receive available posts or Reels even when counts are missing.

What this option does not guarantee

require_play_counts=true is a completeness check, not an independent audit of Instagram’s numbers. It does not make an unavailable count recoverable, add unlimited retries, or guarantee that the number will match every place Instagram displays a view total.

It checks play_count. It does not require every other counter, such as ig_play_count or a separate view-count field, to be present. Those fields should not be treated as interchangeable just because their values sometimes match.

There is also a separate difference between missing counts and a count that does not match the app. Our Instagram posts documentation explains that the returned counts can differ from app totals, including cross-posted Facebook views. Requiring a populated field does not resolve a disagreement over which metric is being compared.

This option is supported on /v2/instagram/user/posts and /v1/instagram/user/reels. It does not change other endpoints or guarantee unrelated optional fields, including a location’s address or city.

How to handle missing counts

If you need captions or media and counts are optional, keep the default behavior and record unavailable counts as unknown. Do not silently turn them into zero in a dashboard, average or ranking.

If you need every returned video’s play count, enable require_play_counts=true. On an incomplete-count error, you can retry a small number of times with a delay or defer that profile until later. Repeated retries are not guaranteed to recover a count, so avoid an endless loop.

If the same posts keep failing, send us the handle, request parameters, approximate request time and affected post URLs or IDs. That lets us check whether the gap comes from an older post, the count lookup, or a problem in our own code. We should investigate that distinction rather than assume every missing count is an unavoidable Instagram limitation.