Which Endpoint Should I Use?

Some of these 645 endpoints do near-identical jobs, and picking the wrong one costs extra credits or returns less than you needed. Each section below answers one "these two look the same, which do I want?" question with the paths and prices side by side.

Costs are per successful call. Failed and cached responses are not charged.

If you start from what you want done rather than an endpoint name, Common jobs lists the calls, a cURL and the price of one run for each job customers most often build.

Start here

Profile, or profile plus posts?

profile is one upstream call that returns the unified author object. profile/full is a composite: the same profile, the account's recent posts, and computed analytics in one call, so you skip the follow-up list request.

If you already hold the handle and only need counts, use plain profile. If your next step is always "and their recent posts", profile/full is one call instead of two.

Instagram: the 1-credit or the 5-credit endpoint?

Instagram is served by two upstreams. The 1-credit endpoints cover the public surface. The 5-credit endpoints unlock data the public surface hides: share counts, follower and following lists, stories, tagged posts, locations, and comment lists.

Note also /v1/instagram/basic-profile (1cr), a slimmer profile payload than /v1/instagram/profile.

A raw list, or the enriched /full list?

For Instagram posts and reels you can pull a plain page or the enriched composite. The plain list is one fast, cheap page. The /full variant fans out per item to attach views, likes, comments, and per-item share counts where available.

Paging a long back catalogue without needing per-item share counts is far cheaper on the plain list. Use /full when you need engagement on every item and want one call.

The two meanings of limit

limit does two different jobs on this API, and on the /full composites it is the one that moves the price.

• Page size. On most list endpoints limit caps a single upstream page and maps to that upstream's native parameter (Naver display, GitHub per_page, and so on). One call, one page, one charge. This is the behaviour Pagination documents.
• Collect-until-N. On a small set of endpoints limit instead tells the endpoint to keep walking upstream pages itself until it has that many unique items, deduping server-side. You are billed per page or window actually consumed, and the unused budget is refunded. Omit limit and the budget is one page, so the price is unchanged.

The collect-until-N endpoints and their ceilings:

So /v1/instagram/profile/reels/full?handle=nike&limit=50 is five pages, not one, and costs 25 credits rather than 5. Budget from the range, not the floor.

Facebook: fill the rows, or fetch them yourself?

Four Facebook list endpoints take an optional include parameter that joins every row on the page to its own detail record inside the same call. Without the parameter the call is unchanged and costs 1 credit. With it, the endpoint holds 1 credit per row, keeps only the rows a fresh lookup actually filled, and refunds the rest, which is why the price below is a range rather than a figure. Rows already in cache are filled for free, and a row Facebook publishes no number for stays null and costs nothing.

Page posts and photos

include=engagement is the move when you are making the list call anyway: the page plus its 3 rows is at most 4 credits in one round trip, where fetching the same three permalinks yourself is the page call plus three /v1/facebook/post calls, at the same 4 credits but four round trips and your own permalink bookkeeping. Two other routes to the same numbers are still the better answer in their own cases.

Reach for /v1/prism/post-stats when the URLs are already in your database and you are refreshing numbers rather than reading a feed, since it takes up to 100 of them at once, across platforms, and refunds the dead ones. Reach for /v1/facebook/profile/reels/full for reels specifically: a flat 5 credits buys a page of 10 reels with exact engagement on every one, which joining ten rows one at a time could not beat.

The two event lists

Both event lists carry the rendered time line, the venue, the city, the start timestamp and the cancelled, past and online flags on post.ext.event with no token at all. What include=details adds is the description, the street address, the coordinates, the hosts, the category, the privacy and the attendance count, plus the cover image and the RSVP counts on a page's own event list, which never carried either. An event's end time and ticket link stay null either way, because Facebook does not publish them for these events.

The join adds 2 to 7 seconds to a page of posts whose rows are not already cached, 2 to 8 seconds to a page of photos, 2 to 6 seconds to a page's own events, 2 to 8 seconds to a city feed of events, never more than 12, and nothing when the rows are cached. Every joined response carries a hydration block itemising the rows, the lookups, the cache hits, the credits held and kept, and the milliseconds, so you can read back exactly what you paid for.

Search one platform, the forums, or everywhere?

Per-platform search is for when you already know the platform. The universal endpoint plans, fuses, and reranks across many platforms at once.

Start with per-platform search (1cr) when the platform is decided. Escalate to /v1/search/everywhere (flat 20cr) only when you genuinely want the cross-platform sweep, not fourteen separate 1cr calls you would have to fuse yourself. The post searches (/v1/tiktok/search, /v1/youtube/search, /v1/reddit/search and their siblings on other platforms), /v1/search/forums and /v1/search/everywhere score each row's relevance to your query by default, free, on computed.relevance. When your keyword is also a common word or another brand's name, add relevance=filter to drop the rows that are about something else, still at no extra credit. When you want to know how people feel rather than what they posted, /v1/search/everywhere and /v1/search/forums count stances for you (data.stance_split). See Labels.

Getting a transcript

Transcript pricing depends on the platform's upstream. YouTube is the cheapest and has two options, the remaining platforms are a flat 10cr, and a composite bundles the transcript with the rest of a video's data.

For YouTube, prefer subtitles (1cr) if you can parse caption files yourself and transcript (3cr) if you want it cleaned. Other platforms only offer the 10cr transcript, for example /v1/instagram/media/transcript, /v1/twitter/tweet/transcript, and /v1/reddit/post/transcript. If you also want the video's stats and top comments, /v1/prism/video-intel is one call.

Which comment endpoint?

Four endpoints touch comments. The distinction is one page versus the whole tree, and a single comment versus a batch re-check.

Use the per-platform post/comments when one page is enough and you want to control paging.

Freshening numbers at scale

When you already hold post or comment URLs and just want current numbers, the batch endpoints re-check many at once and refund the ones that fail. That is cheaper and simpler than looping single calls.

Hiring and job postings

Jobs live entirely on LinkedIn. The split is keyword search versus one company's board, with a cheap counter for when you only want the number.

To track hiring velocity across a competitive set, poll company/job-count (5cr) on a schedule and only spend the 10cr on company/jobs when the count moves.

Ad libraries: which network, which door?

Each network's transparency library has a keyword door and an advertiser door. The keyword door is what you use when you only know a brand name. The advertiser door returns the complete run once you have resolved an id.

Reddit's ad library is currently unavailable: the two reddit/ads/* endpoints are soft-disabled and return 503 at no charge, so there is no live path to give you here. The Ad library aggregation recipe runs the three live networks as one parallel fan-out for 15 credits and records the Reddit gap in full.

App-store intelligence

The App Store and Google Play surfaces are deliberately symmetric: same nine resources, same prices, same parameter names, so one adapter covers both. Swap app_store for google_play and the call is otherwise identical.

For a cross-store view, skip the pairwise calls. /v1/prism/apps-lookup (30cr) resolves one title across both stores in a single composite, and /v1/prism/app-reviews (10-15cr, metered by how many stores you scope) returns reviews from both sides at once.

Commerce, product data, and reviews

Nine marketplaces, one repeating shape: a keyword search that returns ids, then a product call and a reviews call keyed off that id. What differs is which id each marketplace uses.

Two shortcuts worth knowing. /v1/prism/product-reviews (30cr) pulls reviews for one product across marketplaces in a single call instead of you fanning out, and /v1/prism/review-integrity (30cr) runs the same corpus through authenticity checks when the question is "are these reviews real?" rather than "what do they say?". For pricing across sellers on a single item, /v1/amazon/sellers (1cr), /v1/google_shopping/sellers (1cr), and /v1/walmart/offers (5cr) each return the offer list.

Which Prism composite answers my question?

Prism composites fan out across several platforms and return one answered question rather than one platform's rows. They are the most expensive endpoints on the API and the least interchangeable, so pick by the question, not by the price.

Still unsure?

Point a URL at /v1/prism/lookup (0cr) and it dispatches to the correct detail endpoint automatically.