The problem it solves
Each platform that offers an API has its own sign-up and review process, authentication, rate limits, pagination style, error format and field names. Many public data points have no official API at all.
Building on five platforms directly means five integrations to build and maintain, five sets of credentials, and five places where a change can break your product. A unified API moves that work to one provider.
What actually gets unified
- Access: one API key and one bill instead of an account per platform.
- Requests: the same URL pattern, parameters style and authentication header everywhere.
- The envelope: every response wrapped the same way, with the data, cost, request ID and cache status in the same place.
- Errors and paging: one error format and one cursor pattern.
- Shared fields: where platforms measure the same thing, such as followers or views, the field names match.
What stays platform-specific
Platforms do not measure things the same way. A Reddit score is upvotes minus downvotes, not likes. A YouTube view and a TikTok play are counted differently. Some platforms hide counts entirely. A good unified API keeps those differences visible instead of forcing everything into one generic "post" shape that loses detail.
So expect shared fields where the meaning truly matches, and platform-specific fields kept intact next to them.
When a unified API makes sense
| Situation | Better fit |
|---|---|
| You need data from three or more platforms | A unified API |
| You publish or manage posts on your own accounts | The platform’s official API |
| You need public data a platform’s own API does not offer | A data API that reads public pages |
| An AI agent needs social data as a tool | A unified API with an MCP server |
In Monocrawl
One envelope in Monocrawl
Every Monocrawl call follows /v1/{platform}/{endpoint} with an x-api-key header, and every response uses the same envelope: success, data, credits_used, credits_remaining, request_id and cached.
{
"success": true,
"platform": "tiktok",
"endpoint": "profile",
"data": { "…": "platform data, shared fields named the same" },
"credits_used": 1,
"credits_remaining": 4211,
"request_id": "req_…",
"cached": false
}Shared fields use the same names where they mean the same thing. Platform-specific data is kept intact, and the metric semantics page spells out where a number means something different from platform to platform.
Common questions
Is a unified API slower than calling a platform directly?
It adds a small hop, but it often saves time overall through caching and by handling retries and paging for you.
Does a unified API replace official platform APIs?
For reading public data, often yes. For posting, messaging or managing your own accounts, you still need the platform’s own API and permissions.
Are fields exactly the same on every platform?
Only where the meaning matches. Treat platform-specific fields as platform-specific.