White Label Social Media API

White-label social media API for branded dashboards, client portals, and embedded schedulers

A white-label social media API for branded dashboards and client portals. Your interface, our publishing layer.

Power your own branded social media dashboard, client portal, approval flow, or embedded scheduler while bundle.social handles the platform plumbing: account connection, publishing, media uploads, status tracking, analytics, and post errors.

Last updated: November 2026

One API keyNo per-account fees15 platformsAPI key authScheduled publishingOfficial APIs838k+ connected accountsDirect engineer support

Quick start
// Send a client to the hosted connect page with your logo, name and language.const response = await fetch("https://api.bundle.social/api/v1/social-account/create-portal-link", {  method: "POST",  headers: {    "x-api-key": process.env.BUNDLE_SOCIAL_API_KEY,    "Content-Type": "application/json"  },  body: JSON.stringify({    teamId: "client_workspace_456",    socialAccountTypes: ["INSTAGRAM", "FACEBOOK", "LINKEDIN", "TIKTOK"],    redirectUrl: "https://portal.example.com/settings/social",    logoUrl: "https://portal.example.com/logo.png",    userName: "Acme Bakery",    language: "en",    hidePoweredBy: true,    expiresIn: 60  })});const { url } = await response.json(); // redirect the client to url

A branded dashboard backed by brittle platform integrations

  • White-label products need a smooth customer experience while native platforms still create OAuth, media, permission, app review, and error complexity underneath.
  • Clients expect drafts, approvals, calendars, scheduling, publishing status, and clear failed-post messages inside your product, without a vendor dashboard they never asked to use.
  • A branded frontend is hard to maintain when every social platform has different post types, media rules, token behavior, permissions, and failure modes.
  • Building the UI is usually the easy part. Keeping account connection, media handling, retries, status updates, analytics, and support context stable across platforms is the part that eats the roadmap.

What bundle.social handles

  • Keep your own frontend, brand, onboarding, approvals, billing, and customer workflow while bundle.social runs the social publishing infrastructure behind the scenes.
  • Use API-created drafts, scheduled posts, uploads, analytics, webhooks, and status checks inside your customer-facing dashboard or client portal.
  • Give customers a polished branded experience while your operators still have support visibility into failed posts, disconnected accounts, media issues, and platform errors.
  • Launch social media features faster without building and maintaining every platform integration, OAuth edge case, media requirement, and publishing status pipeline yourself.
  • Support many customer workspaces without charging your product model per user, per seat, or per connected social account.

Own the interface, outsource the platform plumbing

White-label social tools win on customer experience. bundle.social gives your product the API layer behind account connection, media uploads, drafts, scheduling, publishing, analytics, status tracking, and readable platform errors, while your users stay inside your brand.

How it works

Connect accounts once, then create and schedule posts with channel-specific fields from one API.

  1. 01

    Send clients to a branded connect page

    POST /api/v1/social-account/create-portal-link returns a link to a hosted page for one team, with your logo and only the platforms you list.
  2. 02

    Save content as drafts

    Your editor creates posts with status DRAFT. A draft is stored with its postDate and per-platform content but does not publish.
  3. 03

    Schedule after approval

    When the client approves in your portal, PATCH /api/v1/post/:id sets status to SCHEDULED. Only DRAFT and SCHEDULED posts can be edited.
  4. 04

    Show the result

    The post.published webhook reports POSTED or ERROR, with per-platform errors and permalinks your portal can display.

Build social media workflows without rebuilding every platform

White-label social media API for branded customer products

A white-label social media API is useful when your customers should experience your product instead of a third-party scheduler. They may need a branded calendar, client portal, approval queue, content editor, AI draft workflow, or reporting dashboard. Underneath that interface, the product still needs account connection, media handling, scheduled publishing, status tracking, analytics, and platform errors.

bundle.social lets you own the customer-facing layer while using one API for the social infrastructure behind it. Your users stay inside your brand, your onboarding, and your permissions model, while bundle.social handles OAuth token storage, platform payload differences, upload references, publishing status, and operational visibility.

The branded UI is only half the white-label product

Drawing the calendar is the smaller job. The larger one is keeping every customer account connected, every media upload valid, every post status understandable, and every platform failure actionable. Native APIs still control permissions, account eligibility, review processes, media rules, and rate limits, even when your interface hides the vendor layer.

Your product owns users, roles, approvals, billing, audit logs, and the branded workflow. bundle.social powers account connection, publishing, scheduling, uploads, analytics, and support context behind the scenes, so the product feels native without your team rebuilding every integration.

Client portals, approval flows, and embedded schedulers

White-label social publishing shows up in many shapes: agency client portals, franchise marketing dashboards, SaaS add-ons, AI content tools, internal approval systems, and embedded schedulers. All of them need the same basic infrastructure, and each product presents it differently.

With bundle.social, your backend can create drafts, schedule approved posts, upload reusable media, inspect failed posts, and fetch reporting data while your frontend controls the workflow. You build a product-specific experience instead of sending customers to a generic social tool that does not match your business model.

API workflows behind a white-label social media product

Everything needed behind the branded surface: account connection, media upload, drafts, approvals, scheduling, publishing, analytics, post status tracking, and platform error visibility.

Branded customer experience

Keep users inside your own UI for calendars, editors, campaign setup, approval queues, publishing status, and reporting while bundle.social handles the API operations behind the scenes.

Embedded account connection

Create a hosted connect link or platform OAuth URLs from your backend and route customers through official OAuth flows without storing platform tokens yourself.

Draft and approval workflows

Create posts as drafts from your app, run your own approval logic, and move content to SCHEDULED after the customer-facing workflow approves it.

Client portal publishing

Let clients, franchise owners, creators, or internal teams review content, approve posts, and inspect publishing status inside your own branded portal.

Support-ready post errors

Expose useful failed-post context in your product and keep deeper operational visibility available to your team through the dashboard.

Multi-workspace scaling

Pair the white-label UX with team-scoped workflows so customer accounts, drafts, scheduled posts, uploads, analytics, and errors stay separated.

Who builds what

What you build and what bundle.social runs in a white-label social media product

The hosted connect page is the only bundle.social screen your clients need to see. Everything after it is your UI on top of the API.

What you build and what bundle.social runs in a white-label social media product
RuleDetails
Connect pagebundle.social hosts it on a bundle.social URL. You set the logo, user name and avatar, back button text, language (19 options) and the platforms offered, and you can hide the powered-by line, the language switcher and the back button or cap how many accounts get connected. The page handles connect, reconnect, disconnect and the Page, channel or location picker. The platform's own OAuth consent screen still appears.
Custom connect screenOptional, and you build it. POST /api/v1/social-account/connect returns the platform OAuth URL for one platform, and POST /api/v1/social-account/set-channel saves the Page, channel or location the client picks.
Composer, calendar and approval queueYou build these. bundle.social stores each post with its status, postDate and per-platform content, and GET /api/v1/post lists a team's posts by status, platform and date range for your calendar.
Approval and editsYour logic decides who approves. On approval, PATCH /api/v1/post/:id moves the draft to SCHEDULED.
Publishing and tokensbundle.social runs this. It stores and refreshes platform tokens and publishes each scheduled post at its postDate.
Status in your portalYou render it from the post. Statuses are DRAFT, SCHEDULED, PROCESSING, REVIEW, RETRYING, POSTED, ERROR and DELETED; REVIEW means TikTok has not returned a final result yet. errors holds a message per platform and externalData the live permalink.
Users, roles, billing and client loginsYou build these. bundle.social has no record of your end users.
Operator viewThe bundle.social dashboard shows your own staff every team's accounts, posts and errors.

Developer example

White-label publishing flow: draft, approve, schedule, status

Examples use bundle.social's public API shape: API key authentication, a post date, selected social account types, and platform-specific data.

TypeScript
// Server-side helper. The API key never reaches the client portal.const api = (method: string, path: string, body?: object) =>  fetch("https://api.bundle.social/api/v1" + path, {    method,    headers: { "x-api-key": process.env.BUNDLE_SOCIAL_API_KEY!, "Content-Type": "application/json" },    body: body ? JSON.stringify(body) : undefined,  }).then((res) => res.json());const teamId = "client_workspace_456";// 1. Account screen: show which platforms the client has already connected.const team = await api("GET", "/team/" + teamId);const connected = team.socialAccounts.map((account: { type: string }) => account.type);// 2. Your editor saves a draft. A DRAFT post is stored but not published.const draft = await api("POST", "/post", {  teamId,  title: "May campaign",  referenceKey: "campaign_may_01",  postDate: "2026-05-14T10:00:00.000Z",  status: "DRAFT",  socialAccountTypes: ["INSTAGRAM", "LINKEDIN"],  data: {    INSTAGRAM: { type: "POST", text: "The May campaign is live.", uploadIds: ["upload_123"] },    LINKEDIN: { text: "Our May campaign is live.", uploadIds: ["upload_123"] },  },});// 3. The client approves in your portal: schedule the draft.await api("PATCH", "/post/" + draft.id, { status: "SCHEDULED", postDate: "2026-05-14T10:00:00.000Z" });// 4. Status screen: read the post back (or wait for the post.published webhook).const post = await api("GET", "/post/" + draft.id);const status = post.status; // SCHEDULED, PROCESSING, POSTED, ERROR, ...const permalink = post.externalData?.INSTAGRAM?.permalink;const instagramError = post.errors?.INSTAGRAM;

Supported content

  • Client portals
  • Branded dashboards
  • Approval flows
  • Embedded schedulers
  • Content calendars
  • Customer publishing workflows
  • AI content tools
  • Agency dashboards
  • Franchise marketing portals

Honest limitations

  • Your product still owns the frontend, customer permissions, approval logic, billing, audit logs, workspace access, and brand experience.
  • Official platform APIs still control permissions, account eligibility, media rules, rate limits, app review requirements, and supported post types.
  • Some customers may still need platform-specific setup steps, account type changes, or re-authentication before every publishing feature is available.
  • Official OAuth screens may still be shown by the social platforms during account connection, even when the surrounding product experience is branded.
  • The hosted connect page is served from a bundle.social URL, and the portal link options have no custom domain setting. Build your own connect screen on the connect endpoint if the address must be yours.

Developer-first infrastructure

Visible post status

Track scheduled, processing, posted, retrying, and error states per post.

Verbose errors

When native APIs fail, we return human-readable error messages and actionable recovery steps.

Flat pricing

No per-post counting. Predictable pricing for teams managing many users, workspaces, and connected accounts.

Same-day support

Direct access to the engineers building the API. We respond to technical issues the same day, sometimes the same hour.

Technical guides & documentation

Questions developers ask before building

Can I build a white-label social media dashboard with bundle.social?

Yes. You can build your own customer-facing dashboard and use bundle.social as the API layer for account connection, publishing, scheduling, media, analytics, status, and errors.

Do my users need to log in to bundle.social?

No. Your backend calls bundle.social with your API key, and the hosted connect page opens from a signed link that expires after 10 minutes by default, or up to 48 hours with expiresIn.

Can I hide bundle.social from my end users?

Mostly. Your dashboard, editor, approvals and status screens are yours, and hidePoweredBy removes the powered-by line from the hosted connect page. That page still runs on a bundle.social URL, and the OAuth consent screens belong to the social platforms. A custom connect screen built on the connect endpoint avoids the hosted page entirely.

Can the social account connection flow be branded?

Yes. The portal link accepts logoUrl, userLogoUrl, userName, goBackButtonText and a language (19 are supported), plus switches to hide the powered-by line, back button, user logo, user name and language switcher. Your backend chooses the team that receives the connected account and the redirectUrl the client returns to.

Can I support client approval workflows?

Yes. Create posts as drafts, run your own client review or approval logic, then change the status to SCHEDULED with PATCH /api/v1/post/:id once the content is approved.

Can this work for many customer workspaces?

Yes. Pair white-label UX with team-scoped workflows so customer accounts, drafts, scheduled posts, uploads, analytics, and errors stay separated.

Is there a demo or starter project?

The docs have an API demo video and an examples page that links a GitHub repo of examples and a Postman collection. The developer example on this page shows the draft, approval, scheduling and status calls in one file.

Can I use this for an AI social media tool?

Yes. AI tools can generate content inside your product, create drafts through bundle.social, keep humans in the approval loop, and publish only after the workflow is approved.

Does white-label publishing bypass platform permissions?

No. Official platform permissions, account types, API rules, media requirements, app review requirements, and rate limits still apply. bundle.social simplifies the integration layer and does not bypass platform rules.

Keep comparing your options