Multi-Tenant Social Media API

Multi-tenant social media API for SaaS platforms, agencies, and customer workspaces

A multi-tenant social media API with isolated customer workspaces, so one tenant's failed post never touches another's.

Model social publishing around separate customers, teams, brands, locations, and organizations without forcing every connected account, scheduled post, upload, analytics record, or platform error into one shared workflow.

Last updated: November 2026

Start your 14-day free trial
View API docs

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

Quick start
const response = await fetch("https://api.bundle.social/api/v1/post", {  method: "POST",  headers: {    "x-api-key": process.env.BUNDLE_SOCIAL_API_KEY,    "Content-Type": "application/json"  },  body: JSON.stringify({    teamId: "customer_workspace_123",    title: "Customer launch post",    postDate: "2026-05-14T10:00:00.000Z",    status: "SCHEDULED",    socialAccountTypes: ["LINKEDIN", "INSTAGRAM"],    data: {      LINKEDIN: { text: "Our customer launch is live." },      INSTAGRAM: { type: "POST", text: "Launch day.", uploadIds: ["upload_123"] }    }  })});

Customer data mixed into one flat social workflow

  • Products with many customers need clean separation between social accounts, scheduled posts, media uploads, analytics, webhooks, and support context.
  • A flat account model becomes risky fast: one customer may have two channels, another may have hundreds of location pages, and both still need isolated workflows.
  • Support teams need to diagnose failed posts by customer workspace without seeing unrelated accounts, uploads, or platform errors from everyone else.
  • Agencies, SaaS tools, franchises, and resellers often outgrow social APIs that charge per account, per seat, or force every client into the same operational bucket.

What bundle.social handles

  • Use team-scoped workflows to keep each customer's connected accounts, scheduled posts, media, analytics, history, and errors separated.
  • Support SaaS, agency, franchise, reseller, marketplace, and internal workspace models without rebuilding the social layer for every customer type.
  • Scale connected accounts around real customer structure while plan usage and official platform limits remain explicit.
  • Give operators and support teams a clear workspace context for every post, retry, failure, upload, and analytics request.
  • Avoid vendor-imposed account caps shaping your product architecture before your customer base has even grown.

Multi-tenancy starts with the teamId on every call

Each customer's accounts, scheduled posts, uploads and errors sit in that customer's team. Your backend picks the team for every request, and webhook events carry the teamId back so you can route them to the right customer as volume grows.

How it works

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

  1. 01

    Map your product to workspaces

    Create a team with POST /api/v1/team for each customer, brand, client, franchise group, location set, or business unit, and store the team ID against that record in your database.
  2. 02

    Connect accounts inside the right team

    Create the connect link or OAuth URL with the customer's teamId. Instagram, TikTok, Facebook, LinkedIn, YouTube, Google Business Profile, and other accounts then belong to that team.
  3. 03

    Create posts with customer context

    Create drafts, scheduled posts and uploads with the same teamId so status, media, analytics, and errors stay attached to the correct workspace.
  4. 04

    Debug and report by workspace

    When a post fails, a token expires, media gets rejected, or analytics need review, filter by team instead of searching one global account pool.

Build social media workflows without rebuilding every platform

Multi-tenant social media API for customer-separated publishing

A multi-tenant social media API matters when one product serves many customers, brands, client accounts, franchise groups, creators, or locations. Each tenant needs its own connected accounts, scheduled posts, media uploads, analytics, post history, and support context. If those objects collapse into one global pool, debugging and customer trust get difficult fast.

bundle.social uses team-scoped workflows so your product can keep every customer's social operations attached to the right workspace. That model is useful for SaaS platforms, agencies, resellers, marketplaces, and internal tools where account count and publishing volume vary heavily from customer to customer.

Why tenant boundaries should exist before the first account connects

Multi-tenancy is hardest to retrofit after customers have already connected social accounts. Decide early how your product maps customers, brands, locations, or clients into bundle.social teams. Then every OAuth connection, upload, post, analytics request, and failure state inherits the right customer context.

That structure keeps operations clean as volume grows. A failed TikTok video, expired Facebook Page token, rejected LinkedIn document, or missing Google Business location shows up inside the tenant that owns it, and support can debug one customer without scanning unrelated accounts in an organization-wide log.

Scale account-heavy products without artificial account caps

Multi-client social products rarely grow evenly. One customer may connect two accounts, another may connect hundreds of local pages or brand profiles. When API pricing or the data model is built around connected-account limits, your product architecture starts bending around vendor constraints.

bundle.social keeps the account model flexible while usage and official platform rules remain explicit. Your application still owns customer roles, billing, approval logic, and audit trails, and the social layer handles many workspaces, many connected accounts, and many scheduled posts through one API.

Customer access

What your application is responsible for

bundle.social separates data by team. Deciding which of your users may read or change which team is your application's job.

Keep the API key on your server

The key is organization-wide. Anyone holding it can read and post to every team, so it never goes into a browser, a mobile app or a customer's hands.

Resolve teamId from the session

Look up the team from the signed-in user's workspace in your own database. Never take a teamId from a request body or URL and pass it on unchecked.

Own roles, approvals and audit logs

Your product defines who can connect accounts, approve, schedule, edit, retry or delete inside a workspace. bundle.social has no record of your end users.

Route events and offboard tenants

Map data.teamId on each webhook event to a tenant before acting on it. When a customer leaves, DELETE /api/v1/team/:id permanently removes the team with its accounts, posts and uploads.

Multi-tenant primitives for real social publishing products

Keep customer workspaces separated while still using one API layer for account connection, publishing, scheduling, media upload, analytics, webhooks, post history, and support visibility.

Customer workspace model

Use teams as customer workspaces for SaaS accounts, agency clients, franchise groups, brands, locations, creators, or reseller-managed customers. Keep each tenant's publishing context clean from day one.

Team-scoped account routing

Use teamId to target the right connected accounts for each customer, brand, or client workspace. Avoid brittle shared-account lookup logic in your own backend.

Separated post operations

Scheduled posts, drafts, processing states, failures, retries, uploads, and analytics stay attached to the workspace that owns them. Support can debug one customer without scanning everyone else.

Many-account customer models

Support agencies, franchises, resellers, marketplaces, and SaaS products where connected accounts vary heavily by customer. bundle.social does not add artificial connected-account caps.

Workspace-aware support context

When a platform rejects media, requires re-authentication, returns a permission error, or delays processing, your operators can see which customer workspace, post, and account are affected.

Reporting expansion path

Build customer-specific reporting from post status, analytics, history import, and platform errors after the publishing path is live.

Data model

Organization, teams and social accounts in a multi-tenant social media API

This is how bundle.social structures tenants. Map your own customers onto it before the first account connects.

Organization, teams and social accounts in a multi-tenant social media API
RuleDetails
OrganizationYour company. It holds the API keys, webhooks, subscription and billing. One API key reaches every team in the organization, and one webhook endpoint receives events for all of them.
TeamOne per customer, brand, client or location group. Social accounts, posts and uploads belong to a team, and almost every endpoint takes a teamId. The Free plan allows 3 teams; Pro and Business have no team cap.
Social accountA connected profile, Page, channel or location inside a team. A team holds one account per platform, so a customer with two Instagram profiles needs two teams.
Post and uploadCreated with a teamId. A post publishes to the accounts connected in its team, and its status, per-platform errors and permalinks stay on the post.
LimitsDaily posting limits count per connected account, so one busy tenant does not use up another's. The monthly post cap counts across the whole organization: 10,000 posts on Pro and 100,000 on Business.
Webhook eventSent to the organization's endpoint. The post or account in data includes teamId, which tells you which customer the event belongs to.

Developer example

Route every request by teamId

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

TypeScript
const BUNDLE_API = "https://api.bundle.social/api/v1";const headers = { "x-api-key": process.env.BUNDLE_SOCIAL_API_KEY!, "Content-Type": "application/json" };// Onboarding: one team per customer, mapped in your own database.export async function createTenant(customerId: string, name: string) {  const res = await fetch(BUNDLE_API + "/team", { method: "POST", headers, body: JSON.stringify({ name }) });  const team = await res.json();  await db.tenants.insert({ customerId, bundleTeamId: team.id });}// The API key reaches every team in the organization, so resolve teamId on the server// from the signed-in user. Never pass through a teamId sent by the browser.async function teamIdFor(session: { userId: string; customerId: string }) {  const tenant = await db.tenants.findForMember(session.customerId, session.userId);  if (!tenant) throw new Error("Forbidden");  return tenant.bundleTeamId;}export async function schedulePost(  session: { userId: string; customerId: string },  input: { title: string; text: string; postDate: string; uploadIds: string[] },) {  const teamId = await teamIdFor(session);  const res = await fetch(BUNDLE_API + "/post", {    method: "POST",    headers,    body: JSON.stringify({      teamId,      title: input.title,      postDate: input.postDate,      status: "SCHEDULED",      socialAccountTypes: ["LINKEDIN", "INSTAGRAM"],      data: {        LINKEDIN: { text: input.text },        INSTAGRAM: { type: "POST", text: input.text, uploadIds: input.uploadIds },      },    }),  });  return res.json();}// Webhooks are organization-wide. Route each event to its tenant by data.teamId.app.post("/webhooks/bundle", async (req, res) => {  const { type, data } = req.body;  const tenant = await db.tenants.findByBundleTeamId(data.teamId);  if (tenant && type === "post.published") await notifyTenant(tenant, data.id, data.status);  res.sendStatus(200);});

Supported content

  • Customer workspaces
  • Team-scoped accounts
  • Scheduled posts
  • Media isolation
  • Customer analytics
  • Post status tracking
  • Workspace-level support context
  • Multi-client publishing

Honest limitations

  • Your application still owns end-user roles, customer permissions, approvals, billing, audit logs, and access control around each workspace.
  • Official platform permissions, account eligibility, app review, rate limits, and media rules still apply per connected account or platform.
  • Plan usage still applies even though bundle.social does not add artificial connected-account caps.
  • A team holds one account per platform. Tenants with several accounts on the same platform need one team per account.
  • Some platform features may require customer-specific setup, account type changes, re-authentication, or additional permissions before they are available.

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

API Reference: Organizations vs Teams

Understand how bundle.social separates organization and team-level workflows.

API Reference: Rate Limits

Daily posting limits per platform and the organization-wide monthly caps.

API Reference: Webhooks

One endpoint for every team, with teamId in each event payload.

Social Media API for SaaS

Review the broader SaaS integration pattern for customer-facing social media features.

Social Media API Architecture Guide

Plan your product architecture around customers, connected accounts, publishing workflows, and support context.

Multi-Tenant Social Media API Architecture

See how to structure organizations, teams, accounts, posts, webhooks, and rate limits in a production social publishing system.

Questions developers ask before building

What is a multi-tenant social media API?

A multi-tenant social media API lets one product manage social publishing for many customers, brands, teams, creators, locations, or organizations while keeping accounts, posts, media, analytics, and errors separated.

Should I create one team per customer?

For most SaaS, agency, franchise, reseller, and marketplace workflows, yes. A team works like a customer workspace in bundle.social. Social accounts, posts, uploads, analytics, and errors stay attached to that team, while your product controls user roles and access.

Can one customer have two accounts on the same platform?

Yes, in two teams. A team holds one connected account per platform, so map each extra Instagram profile, Facebook Page or LinkedIn page to its own team and group those teams under the customer in your database.

How do I stop one customer from seeing another customer's posts?

Your backend enforces it. The API key works across every team in the organization, so look up the teamId from the signed-in user's workspace on the server and never accept a teamId from the client.

Does bundle.social charge per tenant?

No. bundle.social does not charge per user, per seat, per team, or per connected social account on paid plans. The Free plan allows 3 teams. Monthly post caps and official platform limits still apply.

Can agencies use bundle.social for many clients?

Yes. Agencies can structure clients, brands, campaigns, or locations as separate workspaces so publishing operations, account connections, scheduled posts, analytics, and failure visibility stay organized.

Can SaaS products use this behind their own dashboard?

Yes. bundle.social can act as the social media infrastructure layer behind your own SaaS product, content calendar, client portal, AI tool, internal dashboard, or automation workflow.

Do I still need to build permissions in my app?

Yes. bundle.social provides the social API layer, but your product should still control which users can view, connect, approve, schedule, edit, retry, or delete content inside each customer workspace.

Are platform limits shared across all tenants?

Partly. Daily posting limits count per connected account, so each tenant has its own. The monthly post cap is shared by the whole organization (10,000 posts on Pro, 100,000 on Business). Official platform limits depend on the platform and account type, and bundle.social does not bypass them.

Keep comparing your options

Start your 14-day free trial

White Label Social Media API

Build the branded customer dashboard experience on top of the API layer.

Social Media OAuth API

Connect customer accounts into the correct workspace through official platform authorization flows.

Social Media Analytics API

Read customer-specific performance data where platforms allow it.

Social Media Posting API

Create drafts, scheduled posts, and publishing workflows inside each customer workspace.