Choosing an endpoint
Several platforms offer more than one way to read the same thing. How to pick.
Some platforms have several endpoints that look like they do the same job. They exist because they return different shapes, and which one suits you depends on what you are building rather than on which is newer.
Two response shapes
Endpoints fall into two families.
The standardised family returns main and additional. Field names in main
mean the same thing on every platform, so one parser handles Instagram, TikTok
and YouTube together. Choose this when you are comparing across platforms or
writing into a single schema.
The native family returns the platform's own field names and structure. Nothing is renamed or flattened. Choose this when you already work with that platform's own data, or when you want fields the standardised shape does not carry.
Neither is more accurate. They are the same data in different clothes.
Reading one post
| You want | Use |
|---|---|
| A cross-platform post record | The platform's -details endpoint |
| A richer record, same standard shape | The -details-v3 endpoint |
| Instagram's own post object | instagram-post-v4 |
Reading a profile
Most platforms separate the profile header from the post feed, because reading the feed costs more than reading the header.
If you only need follower counts, a name and a bio, use the profile endpoint on its own. Fetching a feed you throw away is the most common way to spend more than you need to.
Comments
Comment endpoints are separate from post endpoints everywhere. Comments live on their own paginated surface, and folding them into a post response would make every post call as slow as the slowest comment thread.
Where a post endpoint offers an include_comments flag, it attaches the first
page only. Use the dedicated comments endpoint when you need the whole thread.
Search
Search endpoints return less per result than a direct read. A search result carries what the results page shows, which is usually an identifier, a caption and a thumbnail.
The normal pattern is two steps: search to find identifiers, then read the ones you care about through the details endpoint. Treat search as discovery, not as a bulk extraction shortcut.
Optional flags cost time
Flags like include_transcript, include_comments and include_subtitles are
off by default because each one adds a fetch. Turning on a transcript flag can
double the time a call takes.
Turn them on for the posts you need them for, not across a whole feed.