White label social media management: How agencies use publishing APIs to resell social under their own brand

White label means your brand, someone else’s infrastructure

Agencies and SaaS builders want to offer social media publishing to their clients without building integrations to eight platforms. White label social media management is the pattern that makes this work: your UI, your brand, your client relationships — backed by publishing infrastructure you do not own or maintain.

The term gets used loosely. Most “white label” social media products fall into two categories:

Done-for-you services. Companies like MixBloom, DashClicks, or Smarcomms manage social content on your behalf, under your brand. You resell their labor. This works for agencies that sell content management, not technology.

Branded SaaS platforms. Tools like SocialPilot, Cloud Campaign, or OnlySocial let you rebrand their dashboard and resell it as your own product. Your clients log into a UI that looks like yours. Underneath, you are running someone else’s software.

There is a third category that neither of those covers: building your own product on top of publishing infrastructure. This is the approach for teams that want full control over the user experience — their own UI, their own scheduling logic, their own data model — without owning the eight platform integrations underneath.

That is what a publishing API enables.

The architecture: your UI, a publishing API, the platforms

The white label stack has three layers:

┌─────────────────────────────────┐
│   Your application (UI + logic) │  ← What your clients see
├─────────────────────────────────┤
│   Publishing API (Postproxy)    │  ← Handles platform integrations
├─────────────────────────────────┤
│   Social platforms              │  ← Instagram, X, LinkedIn, etc.
│   (8 separate APIs)             │
└─────────────────────────────────┘

Your clients interact with your product. Your product calls a publishing API. The publishing API handles authentication, media processing, format conversion, and delivery to each platform. Your clients never see the infrastructure layer.

This is different from rebranding a dashboard. You are not reskinning someone else’s product. You are building your own product and delegating the publishing complexity.

Client isolation with profile groups

The first requirement for white label is isolation. Client A’s social accounts must be invisible to Client B. Their content, analytics, and connected profiles must be scoped.

Postproxy handles this with profile groups. Each profile group is an isolated container for social profiles:

# Create a profile group for each client
curl -X POST "https://api.postproxy.dev/api/profile_groups" \
     -H "Authorization: Bearer YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{"profile_group": {"name": "Acme Corp"}}'

{
  "id": "grp_abc123",
  "name": "Acme Corp",
  "profiles_count": 0
}

Each profile group can have its own scoped API key. A scoped key can only access the profiles and posts within its group — it cannot see other groups, create new groups, or access account-level resources.

This is the foundation of multi-tenant white label. One Postproxy account, many clients, full isolation between them.

Branded OAuth: letting clients connect their own accounts

The second requirement is account connection. Your clients need to connect their Instagram, X, LinkedIn, and other accounts — through your product’s UI, not through a third-party dashboard.

The initialize_connection endpoint generates an OAuth URL scoped to a specific profile group:

curl -X POST "https://api.postproxy.dev/api/profile_groups/grp_abc123/initialize_connection" \
     -H "Authorization: Bearer YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{
       "platform": "instagram",
       "redirect_url": "https://your-product.com/clients/acme/connected"
     }'

{
  "url": "https://app.postproxy.dev/connections/start/abc123...",
  "success": true
}

The flow:

1. Your client clicks “Connect Instagram” in your UI
2. Your backend calls initialize_connection and gets an OAuth URL
3. You redirect the client to that URL
4. They authenticate with Instagram
5. Instagram redirects back to your redirect_url
6. The profile is created in the correct profile group automatically

Your client never sees Postproxy. They see your product, then Instagram’s OAuth screen, then your product again. The infrastructure layer is invisible.

You can subscribe to the profile.connected webhook to update your UI in real time when the OAuth flow completes.

Publishing through the API

Once profiles are connected, publishing from your application is one request:

curl -X POST "https://api.postproxy.dev/api/posts" \
     -H "Authorization: Bearer SCOPED_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{
       "post": {
         "body": "New product launch! Check the link in bio for details."
       },
       "profiles": ["instagram", "facebook", "linkedin", "twitter"],
       "media": ["https://your-cdn.com/product-launch.jpg"],
       "platforms": {
         "instagram": {
           "first_comment": "#productlaunch #newrelease"
         }
       }
     }'

The scoped API key ensures the post goes to the correct client’s profiles. Your application does not need to track which Instagram account belongs to which client — the profile group boundary handles that.

Per-platform parameters let your UI offer platform-specific options (Instagram first comments, YouTube titles, TikTok privacy settings) without your backend knowing anything about how those platforms work internally.

Building a scheduling UI on top of the API

Most white label products need scheduling. Your clients want to queue content for next Tuesday at 9 AM, not publish everything immediately.

There are two approaches:

Direct scheduling. Pass a scheduled_at timestamp when creating a post:

{
  "post": {
    "body": "Tuesday morning content",
    "scheduled_at": "2026-03-17T09:00:00-05:00"
  },
  "profiles": ["instagram", "twitter"]
}

Postproxy holds the post and publishes at the specified time. Your UI handles the calendar interface; the API handles the timer.

Queue-based scheduling. For clients who want recurring timeslots (“post every weekday at 9 AM and 2 PM”), Postproxy’s queues assign posts to the next available slot automatically:

{
  "post": {
    "body": "Content for the next available slot"
  },
  "profiles": ["instagram", "twitter"],
  "queue_id": "queue_xyz789"
}

Queues support priority levels (high, medium, low) and jitter — a random offset of up to 60 minutes that makes automated posting look less robotic. Your clients configure their schedule in your UI; the queue logic runs on the infrastructure side.

Draft and approval workflows

Agencies often need approval before content goes live. A client’s marketing manager reviews posts before they publish. A compliance team signs off on financial services content.

The draft system supports this:

{
  "post": {
    "body": "Pending review by client",
    "draft": true
  },
  "profiles": ["instagram", "linkedin"]
}

Draft posts sit in a draft state until explicitly published:

curl -X POST "https://api.postproxy.dev/api/posts/post_abc123/publish" \
     -H "Authorization: Bearer SCOPED_API_KEY"

Your application owns the approval workflow — who can approve, how many approvals are needed, notification logic, escalation rules. The API provides the hold-and-release mechanism underneath.

Monitoring delivery with webhooks

White label means your brand is on the line. When a post fails to publish to TikTok, your client contacts you, not the infrastructure provider. You need visibility.

Postproxy webhooks deliver real-time notifications for every publishing event:

• platform_post.published — a post went live on a specific platform
• platform_post.failed — a post failed on a specific platform, with the reason
• platform_post.failed_waiting_for_retry — a post failed but will be retried automatically
• profile.disconnected — a client’s token expired or was revoked

Each event fires per platform, not per post. A post to four platforms generates four webhook deliveries. Your application knows exactly what succeeded and what needs attention, per client, per platform.

This is what separates infrastructure-backed white label from dashboard reselling. You have programmatic access to every outcome, not a notification in someone else’s UI.

Analytics per client, per platform

Your clients expect reporting. Post performance, engagement trends, cross-platform comparisons — all branded as your product.

The stats endpoint returns engagement snapshots over time:

curl "https://api.postproxy.dev/api/posts/stats?post_ids=post_abc,post_def&profiles=instagram,twitter" \
     -H "Authorization: Bearer SCOPED_API_KEY"

Stats are broken down by platform with platform-specific metrics:

Snapshots are stored over time, so you can build trend charts — not just “how did this post do” but “how is this client’s engagement trending this month.” All scoped by profile group, so Client A’s data never leaks into Client B’s reports.

How this differs from SocialPilot, Vendasta, and Cloud Campaign

The existing white label social media products are designed for agencies that want to resell a dashboard. You get their software with your logo. Configuration options vary — custom domains, branded emails, logo placement — but the product is theirs.

That works if the dashboard fits your needs. It does not work if:

• You are building a SaaS product with social publishing as a feature, not the core product
• Your UI has specific requirements that a reskinned dashboard cannot satisfy
• You need programmatic control — publishing triggered by events, AI-generated content pipelines, automated workflows
• You want to own the user experience end-to-end, not configure someone else’s

A publishing API is infrastructure, not a product you resell. You build the product. The API handles the part that would otherwise require you to maintain integrations with Instagram’s container model, X’s OAuth 1.0a flow, LinkedIn’s chunked video uploads, TikTok’s scope verification, and every other platform-specific implementation detail.

What Postproxy handles in a white label setup

• Profile isolation — profile groups with scoped API keys for per-client data boundaries
• OAuth delegation — branded connection flows where your clients connect accounts through your UI
• Platform integrations — eight platforms, each with their own auth model, media upload protocol, and content rules
• Scheduling and queues — timed publishing and recurring timeslot queues with priority and jitter
• Per-platform outcomes — individual success/failure status for every platform on every post
• Webhook delivery — real-time notifications for every publishing event, profile connection, and failure
• Analytics normalization — engagement metrics from every platform in a consistent format, with historical snapshots

Build your white label social media product on the Postproxy API. Connect your first client’s accounts in minutes, not months.