Unified Social Media API: Read and Write Posts, Profiles,

Published September 8, 2026 · Last updated October 8, 2026

September 8, 2026

Unified now supports a new category: Social Media.

The Unified Social Media API gives you one social media API for the platforms your end-customers already run. You read and write posts, read profiles and their metrics, read reviews and reply to them where the platform allows it, and read post-level and profile-level insights. Every request is executed directly against the customer's platform at the moment you make it, so what you read is what exists in their account right now. Nothing is cached and no end-customer data is stored.

Object and field coverage differs by integration, because each platform's own API determines what Unified can support. Field support, webhook support, and list parameters are documented per integration.

A social media API reads and writes posts, profile data, reviews, and engagement metrics from the platforms where that data lives. That can be a publishing surface like Instagram, LinkedIn, or Threads, a review surface like Trustpilot, or a listing that carries both, like Google Business Profile. The Unified Social Media API serves all of it through four unified objects with the same field names across every integration, so the product you build once runs against whichever platform each customer happens to use.

Social Media is its own category because it covers two distinct jobs that share one data model: distribution and reputation. Posts and insights carry the first, profiles and reviews the second. The same customer account authorizes both, and the same four objects carry both, which is why they sit in one category rather than two.

The integration list makes the point on its own. Trustpilot and Google Business Profile sit alongside Instagram, Threads, and Bluesky. A review left on a Google listing and a comment left on a Pinterest pin are the same shape of problem for a product team: customer-authored content attached to a profile the customer owns, on a platform with its own auth model and its own content rules.

Access to social platforms is also gated before any code runs. Each one operates its own developer program, its own app review, and its own approval path ahead of a single production call, and the approval criteria differ by platform and by scope. That work is not integration work in the usual sense. It happens before any code you write matters, and it recurs every time a platform revises its terms.

Each social platform models posts, profiles, reviews, and metrics in its own API, with its own names, shapes, media handling, and identity model, so supporting a second platform natively means building and maintaining a second integration, plus a second developer program approval. Against the Unified Social Media API, the second platform is the same four objects on a different connection.

What changes	Building per platform	Building on Unified
Integration work	A separate integration for each platform	One integration against four unified objects
Data model	Each platform's own names, shapes, and media handling	Post, Profile, Review, Insight with the same field names across integrations
Identity	A different account and profile model per platform	`profile_id` references on posts, reviews, and insights
Writes	Each platform's own create, schedule, and reply semantics	Create, update, and remove posts; update review replies; the same request shape across integrations
Authorization	Separate auth, scopes, and app review per platform	Unified's authorization component, one connection per end-customer
Data currency	Whatever your sync interval is	Unified pass-through architecture: requests are executed directly against the source API on each call
Maintenance	Rework each integration when its API or its terms change	Schema changes absorbed behind the unified objects
Coverage	Whatever you build, on the platforms you build for	Documented per integration and per field

The four objects support publishing, review response, listing management, and reporting products, all against the same customer connection.

Publishing products that create posts with body, media, and type, then read status and the live url back to confirm what actually went out
Review inboxes that read reviews with rating, content, and author across a customer's listings, and write the business's reply back where the platform accepts it
Social reporting products that read insights as metric and value pairs bucketed by period, without maintaining a separate metrics pipeline per platform
Local listing management that reads a listing's category, phone, and structured postal address, and follows parent_id from the account down to each location a customer runs
Threaded conversation products that read and write replies through parent_post_id
AI agents that draft a reply to a review or a post at request time, reading the current rating, the current comment, and the current engagement before they write

The last one is why this category matters for AI products specifically. An agent drafting a response to a one-star review needs the review as it stands, including whether a human has already replied. An agent recommending a posting time needs this week's engagement, not last week's. A copied metric is a guess about the present, and on social platforms the present moves in minutes.

The Social Media category covers 16 integrations, including:

Not every integration carries every object, because the platforms themselves do different jobs: a review platform has no posts to return, and a publishing platform has no reviews. Which objects and fields each one supports is documented on the Supported Integrations page, the current source as coverage extends.

The social media API provides four unified objects. The Post, Profile, Review, and Insight data models are the full reference:

Post — a post or comment, carrying body, an optional title, a media array, language, a scheduled_at timestamp, a call_to_action, and the public permalink. A status runs DRAFT, SCHEDULED, PUBLISHED, REJECTED, PROCESSING, and DELETED. A type separates a post from a reply, repost, quote, or story, and covers the event, offer, and alert formats listing platforms use. profile_id points at the account that owns it, parent_post_id at the post it replies to or quotes, and a metrics object carries its engagement counts
Profile — an account or listing, with display name, the username, handle, or store code, description, category, avatar_url, the profile url, and the website_url it links out to. Contact and location arrive as phone, a free-text location, and a structured address carrying two street lines, city, region, postal code, and country. is_verified and is_private flag the account state, parent_id nests a location under an account, and a metrics object carries follower, following, and post counts
Review — a review left on a customer's profile, with a star rating, title and content, the author's display name, avatar, and free-text location, and the public permalink. profile_id points at the listing being reviewed, and a nested reply object carries the business's response with its own created and updated timestamps
Insight — a single metric reading, with a date, a numeric value, and a period running DAY, WEEK, MONTH, LIFETIME, and TOTAL. The metric comes from a shared enum covering followers, following, posts, impressions, reach, engagement, profile views, clicks, video views, likes, comments, shares, and saves. profile_id scopes the reading to an account, and an optional post_id scopes it to one post

Media, call-to-action, and engagement counts are structured data inside the Post object rather than separate endpoints. One request returns each media asset with its URL, alt text, media type, height, width, and position in the post; the call-to-action with its button type and destination URL; and six engagement counters covering likes, comments, shares, quotes, views, and bookmarks.

The same holds on the other objects. Profile carries its postal address as a structured object rather than six flat fields or a second lookup, with audience counts alongside it. Review carries the business's response as a nested reply object with its own text and its own created and updated timestamps, so a review product can tell whether a reply exists, when it went up, and whether it has since been edited, from the request that returned the review.

If you are scanning a comparison for a media, address, reply, or engagement resource, at Unified those are fields on their parent object rather than separate objects to fetch and join. The Insight object is the one genuine separation: a time-bucketed series for reporting over a window, rather than a current total.

The metric enum is where the reporting side of the normalization work shows. Every platform names its engagement measures differently, and impressions, reach, and views are three different things that get used interchangeably across vendor documentation. Insight returns one of thirteen named metrics regardless of which platform served it, so a chart built against IMPRESSIONS keeps its meaning when a customer adds a second account on a different platform. Read period alongside value when you do. The same metric arrives bucketed by day, week, or month on some platforms and as a LIFETIME or TOTAL figure on others, and a daily reach charted against a lifetime reach is a reporting bug rather than a trend.

Profile carries two location fields that do different jobs. The free-text location is a locale string, the kind a handle sets on a personal account. The structured address is a postal address, the kind a listing carries. They are not variants of each other, and which one an integration returns follows what its platform models, so read the one the integration returns rather than assuming either is the general case.

Unified provides access to platform-specific fields through the raw field on every object.

What can you write, and what happens to a write?

Posts support create, update, and remove, and every write is executed directly against the customer's platform rather than applied to an intermediate copy. Reviews support retrieve, list, and update, and update is how a reply is written back. Profiles support retrieve and list only, and insights support retrieve and list only. Method support extends as the category does, so the docs are the current source for what each object supports.

Which fields are writable differs by integration, because each platform's own API sets what it accepts, and some fields are required rather than optional. That follows each platform's own rules: a post to Instagram or Pinterest will not publish without media, because neither platform accepts a text-only post. Writable and required fields per integration are documented in the capability matrix.

Write support is narrower than read support, as it is across every category: social platforms guard writes tightly, gate them behind app review, and restrict several of them by account type, and a unified layer inherits every one of those rules. Check the matrix against the platforms your customers actually run.

Publishing is public and immediate. A post goes out, a reply appears under a review, and both are visible to everyone the moment they land, so the write path is the part of this category a customer notices first when it lags.

Every social media object is listed at GET /social/{connection_id}/{object} and retrieved at GET /social/{connection_id}/{object}/{id}, so the request shape is the same whichever object you are after and whichever platform the connection points at. Writes follow the same shape: a post is created at POST /social/{connection_id}/post.

Two query parameters apply across the category. fields limits the response to the fields you name. raw passes vendor-native parameters through to the source API, URL-encoded, for filtering the unified model doesn't cover.

Each object takes the list parameters its own shape calls for. Post, profile, and review lists take limit and offset for paging. Posts filter on profile_id, and on updated_gte to return only records changed since a timestamp. Profiles filter on parent_id to read the locations nested under an account. Reviews filter on profile_id. Insights take start_gte and end_lt to bound a period, profile_id to scope to an account, and post_id to scope to a single post. Which parameters each integration supports, and which it requires, is in the capability matrix.

Insights are read by date window rather than by page. There is no limit or offset on the Insight object at all, so a reporting product reads a bounded period rather than walking a cursor through a list.

Where an integration supports updated_gte on posts, a product reads only what changed since its last call. Where it doesn't, a list request returns what the platform returns for the filters you supply, and the product reads on a schedule it sets. That is a per-integration question rather than a category-wide one.

Which changes can you receive as webhooks?

Unified detects changes on the Post object and delivers events to your endpoint, so a product can react to a change rather than read for it. The available events are social_post_created and social_post_updated.

Support varies by integration, and the integrations without webhook support read on a schedule you set. There are no deleted events in the social media category as of September 2026.

Reading on a schedule is not the same thing here as it is on a stored-copy architecture. Because every Unified request is executed directly against the source API, a scheduled read returns what exists in the customer's account at the moment of the call. A scheduled sync against a cached copy returns what was true when the sync last ran. The interval determines how often you look; it does not determine how old the answer is.

Example build

A cross-platform publishing module inside your product, so a customer's team posts to every account they run without leaving it:

Each customer authorizes their social platforms through Unified's authorization component. You store one connection ID per customer.
You list Profile objects for each connection to render the accounts the customer can post from, using the profile_id, name, and username each one returns.
Your composer collects the fields the target integration accepts: body for the text, media for photos and video with alt text and ordering, title where the platform uses one, and call_to_action where it supports a button.
You create the post through Unified and the write is executed against the customer's platform. You read status and the public url back to confirm what went out, including the REJECTED and PROCESSING states a platform can return.
You read post metrics for current engagement counts, and Insight records for the same measures bucketed over a period.
Where the platform threads, you write replies through parent_post_id.

The same code runs against every customer. What varies is which fields each platform accepts, not whether the feature works.

Real-time by design

Every request is executed directly against the source API rather than served from a stored copy.

Requests are stateless. No end-customer social data is cached, synced, or stored at rest on the request path. That matters in this category for two reasons. Engagement metrics and review counts change continuously, so a stored copy is wrong by definition and wrong at an unknown magnitude. And review content, author details, and private profile data are customer-owned records that stay inside the platform the customer already chose.

The Social Media API is one of 36 categories and 1484 integrations on Unified, and is available on all plans.

→ Start your 30-day free trial → Book a demo

Frequently asked questions

What is a unified social media API?

A unified social media API provides one interface for reading and writing posts, profiles, reviews, and engagement metrics across multiple social platforms. Instead of building against Instagram, LinkedIn, and Trustpilot separately, developers integrate once and work with the same object names and fields regardless of which platform an end-customer runs.

Which objects and fields are supported on which platforms?

Coverage differs by integration and changes as integrations are added and extended. The Supported Integrations page lists field support, webhook support, and list parameters for every integration in the category, and is the current source rather than any figure quoted elsewhere.

Can I schedule posts through the Unified Social Media API?

Scheduling is expressed in the schema: the Post object carries a scheduled_at timestamp and the status enum carries a SCHEDULED value. Whether a given integration accepts scheduled_at on a write depends on whether its platform supports scheduling in its own API. Where it doesn't, scheduling stays in your application and you create the post through Unified when it is due.

Can I write posts, or only read them?

Posts support create, update, and remove. Reviews support update, which is how the business's reply is written back. Profiles and insights are read-only. Writes are executed directly against the customer's platform rather than applied to an intermediate copy.

Does Unified store social media or review data?

No. Unified does not store end-customer data at rest on the request path. Each request is executed directly against the customer's platform and the response is returned without being cached or written to a database, which keeps review content, author details, and private profile data inside the platform the customer already chose.

Author

Written by Mallory Greene

Mallory Greene is Head of Marketing at Unified.to. She writes about integration infrastructure, unified APIs, and MCP for technical teams. Based in Toronto.

All articles

Unified Social Media API: Read and Write Posts, Profiles, Reviews, and Insights Across Social Platforms