Build your agency's social media dashboard with Claude Code

By Sunday night you can have a dashboard that shows every client's comments, DMs, and Google reviews in one queue and publishes to seven networks with scheduling. You build the screens with Claude Code; SocialAPI.ai supplies the API underneath at $109 a month for 50 client profiles. The per-seat route costs $23,940 a year for five Sprout Social Advanced seats (sproutsocial.com/pricing, retrieved 10 August 2026). This tutorial walks the build end to end.

What you're building

Agencies that leave per-seat suites rebuild three screens, and only three. A queue: what goes out this week, per client. An inbox: everything that came in overnight, across every client and network, with a reply box. An approval screen: a link a client opens on a phone and taps yes. Analytics, listening, and ad reporting are out of scope on purpose; the cost section below explains what that omission buys you.

The architecture is boring by design. Your Next.js app renders those views and calls one REST API. SocialAPI.ai sits between the dashboard and the platforms, normalizes comments, DMs, mentions, and Google Business Profile reviews into one Interaction schema, and absorbs each network's auth and rate limits (the per-network capability matrix is on the platforms page). During the build, Claude Code talks to the same API over MCP, so it writes code against live responses instead of guessed ones.

Prerequisites

Everything on this list is free at the scale a first build needs.

• A SocialAPI.ai account with one client's socials connected: the free Hobby tier covers 2 client profiles, 10 posts, and 50 interactions a month, enough to build and demo before paying anything.
• Claude Code installed and signed in (npm install -g @anthropic-ai/claude-code); any MCP-capable editor also works, and the FAQ below covers Cursor.
• Node.js 20 or newer, which both Claude Code and a current Next.js app expect.

Step 1: connect the MCP server

SocialAPI.ai's MCP server is remote: one HTTP endpoint at https://api.social-api.ai/mcp, nothing to install, and authorization over OAuth 2.1 with PKCE rather than a pasted key (integration docs, retrieved 12 August 2026). Register it once:

# Register the server for this project
claude mcp add socialapi --transport http https://api.social-api.ai/mcp

# Or once for every project on your machine
claude mcp add socialapi --transport http --scope user https://api.social-api.ai/mcp

# Confirm it shows up
claude mcp list

The first time a tool runs, Claude Code opens your browser to authorize; approve it and the session gains 75+ tools spanning accounts, publishing, comments, DMs, media, reviews, mentions, and webhooks. Your dashboard authenticates differently. Create an API key in the SocialAPI.ai dashboard (keys carry a sapi_key_ prefix), put it in .env.local as SOCIALAPI_KEY, and never let it reach the browser: every call belongs in a route handler or server component.

Step 2: scaffold the dashboard

Resist asking for the whole dashboard in one prompt. Claude Code does its best work when every prompt ends in something you can run, so the sequence that held up for us is scaffold, inbox, queue, approvals, one commit per step. The opening prompt sets the frame and, more importantly, tells the model to use its MCP tools before writing a line:

Create a Next.js 15 app (App Router, TypeScript, Tailwind) called
agency-dash. It talks to the SocialAPI.ai REST API at
https://api.social-api.ai/v1, authenticating with the SOCIALAPI_KEY
env var as a Bearer token.

Before writing any code, use your socialapi MCP tools to list my
connected accounts and fetch one page of inbox conversations. Mirror
the exact JSON field names you see in the TypeScript types.

Build three routes: /inbox, /queue, /approvals. Put one typed fetch
wrapper in lib/socialapi.ts. No client-side API calls: everything
goes through route handlers or server components.

The MCP connection is what separates this from pasting documentation into a chat window. Mid-task, Claude Code can call the same tools your agent would use in production (create_post, reply_to_comment, and dozens more), so the Interaction type it writes comes from a response it actually fetched. Review every diff the way you would a junior developer's pull request. The code is about to be yours; read it like it.

Step 3: the unified inbox

One endpoint feeds the whole inbox screen. GET /v1/inbox/conversations returns comments, DMs, mentions, and Google Business Profile reviews across every connected client in one data envelope, cursor-paginated, with the same field names for every platform (endpoint reference). That sameness is the entire trick: the inbox component ships with zero per-network branching.

curl https://api.social-api.ai/v1/inbox/conversations \
  -H "Authorization: Bearer $SOCIALAPI_KEY" | jq

# Response (same shape for every platform)
{
  "data": [
    {
      "id": "sapi_cmt_...",
      "type": "comment",
      "platform": "instagram",
      "author": { "username": "designfan" },
      "text": "Where can I buy this?",
      "created_at": "2026-08-10T14:32:00Z"
    },
    { "platform": "google", "type": "review", "rating": 4 }
  ],
  "pagination": { "next_cursor": "<cursor>" }
}

// app/inbox/page.tsx
type Interaction = {
  id: string;
  type: "comment" | "dm" | "mention" | "review";
  platform: string;
  author?: { username: string };
  text?: string;
  rating?: number;
  created_at: string;
};

export default async function InboxPage() {
  const res = await fetch(
    "https://api.social-api.ai/v1/inbox/conversations",
    {
      headers: { Authorization: "Bearer " + process.env.SOCIALAPI_KEY },
      next: { revalidate: 60 },
    },
  );
  const { data } = (await res.json()) as { data: Interaction[] };

  return (
    <ul className="divide-y">
      {data.map((item) => (
        <li key={item.id} className="py-3">
          <span className="font-mono text-xs">{item.platform}</span>{" "}
          <strong>{item.author?.username ?? "reviewer"}</strong>{" "}
          {item.text ?? item.rating + " stars"}
        </li>
      ))}
    </ul>
  );
}

Replies go back through the same surface: a DM reply is POST /v1/inbox/conversations/:id/messages, and comments and reviews respond through their own unified endpoints while SocialAPI.ai enforces each platform's quirks underneath, like Meta's 24-hour messaging window. Prompt for the reply box only after the list renders. Polling with a 60-second revalidate ships the demo; for production, subscribe to webhooks, which arrive signed and retry 5 times on an exponential backoff schedule (immediate, ~30s, ~5m, ~30m, ~3h), so the handler must deduplicate.

Step 4: scheduling and approvals

Publishing is one call, and scheduling is the same call with one extra field. POST /v1/posts takes a caption and a platforms array; add schedule_at with a future timestamp and the post waits in the queue instead of going out now.

# Publish now for one client
curl -X POST https://api.social-api.ai/v1/posts \
  -H "Authorization: Bearer $SOCIALAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "caption": "Fresh roast drops Friday.",
    "platforms": ["instagram", "facebook"]
  }'

# Add schedule_at to queue it instead
curl -X POST https://api.social-api.ai/v1/posts \
  -H "Authorization: Bearer $SOCIALAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "caption": "Fresh roast drops Friday.",
    "platforms": ["instagram", "facebook"],
    "schedule_at": "2026-08-21T15:00:00Z"
  }'

# Response (trimmed)
{
  "status": "scheduled",
  "platforms": [
    { "platform": "instagram", "status": "scheduled" },
    { "platform": "facebook", "status": "scheduled" }
  ]
}

Approvals force a design decision the API deliberately leaves to you. SocialAPI.ai's posts:write scope grants create, edit, publish, and delete as one unit, so the human gate has to live in your service: drafts sit in your own database, the client taps approve on /approvals, and only then does your route handler call POST /v1/posts with the real key. We unpack the scope model in the multi-account API guide.

Close the loop with the posts webhook family (post.published, post.partial, post.failed), and render all of it honestly in the queue screen. A green check that appears when the publish call returns, rather than when every network confirms, will cost an account manager a client call someday.

What this costs, honestly

The subscription math is lopsided enough to state plainly. Full Send runs $109 a month for 50 client profiles, about $2.18 per client, and adding teammates changes nothing because there are no seats. Five Sprout Social Advanced seats cost $1,995 a month, $23,940 a year (sproutsocial.com/pricing, retrieved 10 August 2026). Even after hosting and an AI coding subscription, the owned dashboard lands below a tenth of the per-seat bill; the vendor-by-vendor detail is in our Sprout alternatives comparison.

The maintenance trade decides whether this stays a good idea in month six. When Meta ships a breaking Graph API change, that is SocialAPI.ai's incident; your dashboard keeps calling the same /v1 contract. When the inbox crashes on a review with no author, that bug is yours at 9 a.m. on a client day. You own UI bugs, uptime, and every feature request your account managers invent. SocialAPI.ai owns platform drift, token refresh, and app reviews. Budget a few hours a month for your side, not zero.

When you should not build this

Three cases where a suite wins on merit, and pretending otherwise would cost you more than a subscription.

• Nobody owns code. If no employee or contractor will maintain a small TypeScript app next quarter, a dashboard you prompt into existence this quarter is abandonware with clients attached. Metricool's per-brand plans run $67 to $210 a month at 15 to 50 brands; it and the other SaaS options are compared in our Hootsuite alternatives round-up.
• Social listening is a contracted deliverable. SocialAPI.ai does not offer listening, and building sentiment tracking across 30 networks is a data-engineering program, not a weekend. A suite with a real listening product, Sprout above all, stays the honest answer.
• Procurement wants an SLA on the UI itself. Your weekend build cannot sign one. Buy the dashboard in that case, or run SocialAPI.ai underneath a commercial front end and let each vendor sign for its own layer.

Questions agencies ask before building

Can Claude Code really build a social media dashboard?

Yes, with one qualification: it builds the dashboard layer, which in 2026 is ordinary CRUD UI over a stable REST API. Connected to SocialAPI.ai over MCP, Claude Code inspects live endpoints while it writes, so the types and field names match real responses. What it does not build is the platform layer (OAuth, app reviews, rate limits); that stays on the API vendor permanently. Review every diff as you would a junior developer's pull request, and the result is a codebase your team can own.

What does the SocialAPI.ai MCP server do?

It exposes the SocialAPI.ai REST surface as 75+ MCP tools: accounts, publishing, comments, DMs, media uploads, Google Business Profile reviews, mentions, webhooks, and usage. It runs remotely at https://api.social-api.ai/mcp with OAuth 2.1 (PKCE), so there is no binary to install and no key to paste into your editor. During a build, that means Claude Code can list your real connected accounts or fetch a real inbox page before writing the code that consumes them.

How long does it take to build an agency dashboard with AI?

A weekend gets a working version of the three core screens (inbox, queue, approvals) against SocialAPI.ai's API; that estimate assumes someone comfortable reviewing TypeScript. Client-ready polish is slower: white-labeled report exports and analytics take weeks. If you are migrating from a suite, add 2 to 6 weeks of parallel running for client re-authorization and queue rebuilding, timed against your current tool's renewal notice window.

What happens when platform APIs change?

That is the layer you rent instead of own. Meta versions its Graph API every few months, TikTok and LinkedIn change scopes and review requirements on their own schedules, and SocialAPI.ai absorbs those changes behind the stable /v1 contract your dashboard calls. Your code keeps reading the same Interaction schema. The reverse is also true: when your UI breaks, that is your commit to fix, which is exactly the trade this tutorial asks you to accept.

Do I need Cursor or Claude Code specifically?

No. The MCP server works with any MCP-capable client: Cursor, VS Code with Copilot, Claude Desktop, ChatGPT, or a custom agent (setup guides). Only the Step 1 command is Claude Code-specific; Cursor registers the same https://api.social-api.ai/mcp URL through its own MCP settings. You can even skip MCP entirely and build against the REST docs, though then your tool cannot check live response shapes while it writes.

If the trade reads right for your roster, start where the risk is zero: connect two clients on the free tier, run the Step 1 command, and see whether the inbox screen Claude Code builds on Saturday is one your team would work in on Monday. The agency solution page covers client workspaces and migration order, and contact us to scope the build against your actual client list.

Sources, checked 10 to 12 August 2026: SocialAPI.ai docs: Claude and Claude Code setup · SocialAPI.ai docs: AI integrations overview · SocialAPI.ai API reference: list inbox conversations · Claude Code docs: connect tools via MCP · Sprout Social pricing · SocialAPI.ai pricing