Each platform in its own shape

The first design of this API had one schema. A profile was a profile whether it came from LinkedIn, Instagram or TikTok, a post was a post, and anything that did not fit went into a bag called platform_fields. It read well. It was the wrong call, and we took it out before anyone had integrated against it.

What one schema cost

The four platforms are four different systems. A LinkedIn profile is a CV: a headline, experience, education. A TikTok account is a follower count and a running total of likes. The shared “profile” was the thin overlap — a name, a handle, a follower count — and almost everything anyone actually came for was in the bag, one level down and loosely typed. A shared “post” put an Instagram view and a TikTok view in the same column, and they are not the same measurement.

Named the way the platform names it

Each object now uses the field names of the platform’s own developer API wherever one describes the same thing. Google Maps fields are the Places API’s: formatted_address, user_ratings_total, opening_hours.weekday_text. Instagram’s are the Graph API’s: followers_count, media_type, permalink. TikTok’s are its Display and Research APIs’: follower_count, video_description, hashtag_names. LinkedIn has no public data API, so its fields are the words on the page: headline, about, experience.

If you have read the platform’s docs, you already know ours. And what each platform has that the others do not — popular times on a place, the sound on a video, the paid-partnership label on a post — is a documented field at the top level, not something to dig out of a bag.

What stayed the same

The conventions, not the shapes: one envelope, one error format, snake_case, timestamps in ISO 8601, the platform’s own ids as strings. Every documented key is present on every call, so you can read a field without first checking that it exists.

And null is still not zero. When a platform does not show a value, the field is null — never 0, never an empty string. A follower count of zero and a follower count nobody told us are different facts, and an API that blurs them will eventually put a wrong number in someone’s report.

{
  "data": {
    "username": "nasa",
    "display_name": "NASA",
    "follower_count": 1234567,
    "likes_count": 40211876,
    "is_verified": true
  }
}

Every object is documented field by field in the response objects, and the MCP server returns the same ones, so an agent that prototypes with one and ships the other finds them identical.