Migrating from Ayrshare to Naive

• Publishing lives behind an Ayrshare API key, and per-end-user separation is an Ayrshare Profile Key (Business plan) — an identity that exists only inside Ayrshare, unrelated to where the same agent’s cards, email, and KYC live.
• Whether the agent may post, and how much it may spend doing so, is not something Ayrshare governs — it is a key you hold. There is no execution-time “can this agent post right now?” check tied to the agent’s broader permission set.
• “Which agent posted this, for which end-user, and who let it?” is answered in Ayrshare’s post history for social, and in unrelated systems for the agent’s spend, comms, and identity.

• The Account Kit that decides whether the agent may issue a card, send email, or buy a domain also decides whether it may use social at all — checked at execution time, not in a separate dashboard.
• Publishing spend is metered in the same credit balance and budget ceiling as every other primitive, so a runaway agent hits one cap, not a separate Ayrshare bill.
• Every post records the acting agent and lands in the same per-user activity log as its card spend, email sends, and KYC events.

​

Concept map

​

Before / after: the core path

import SocialMediaAPI from "social-media-api";

// One account-wide API key. On the Business plan you scope an end-user by
// passing their Profile Key — an identity that exists only inside Ayrshare.
const social = new SocialMediaAPI(process.env.AYRSHARE_API_KEY!);

// 1. Publish now (POST /api/post)
const post = await social.post({
  post: "We just shipped agent-native social posting!",
  platforms: ["twitter", "linkedin"],
  mediaUrls: ["https://cdn.example.com/launch.png"],
  profileKeys: [process.env.ACME_PROFILE_KEY!], // Business plan, per end-user
});

// 2. Pull analytics for the post (POST /api/analytics/post)
const stats = await social.analyticsPost({
  id: post.id,
  platforms: ["twitter", "linkedin"],
});

// The card, inbox, phone, and KYC for this customer's agent live in entirely
// separate systems — and whether the agent "may post" is a key you hold, not a
// governed, execution-time decision.

import { Naive } from "@usenaive-sdk/server";

const naive = new Naive({ apiKey: process.env.NAIVE_API_KEY! });
const client = naive.forUser("acme"); // same id space as your own users

// 1. Publish now (POST /v1/social/posts) — platforms are UPPERCASE
const post = await client.social.createPost({
  content: "We just shipped agent-native social posting!",
  platforms: ["TWITTER", "LINKEDIN"],
  media_urls: ["https://cdn.example.com/launch.png"],
  publish_now: true,
});

// 2. Pull analytics for the post (GET /v1/social/posts/:id/analytics)
const res = await fetch(
  `https://api.usenaive.ai/v1/social/posts/${post.id}/analytics`,
  { headers: { Authorization: `Bearer ${process.env.NAIVE_API_KEY}` } },
);
const { analytics } = await res.json();

// Whether this agent may post at all is its Account Kit's `social` primitive,
// checked at execution time; the 1-credit publish counts against the SAME
// budget ceiling as its cards, email, and phone — and the post is logged
// against the acting agent.

• Platform names are uppercase. twitter → TWITTER, linkedin → LINKEDIN, etc. Naive supports TWITTER, LINKEDIN, INSTAGRAM, FACEBOOK, TIKTOK, YOUTUBE, THREADS, PINTEREST, REDDIT, BLUESKY, and MASTODON.
• post → content, mediaUrls → media_urls. Naive downloads each media URL and attaches it to media-capable platforms; text-only platforms are unaffected.
• Publish is explicit. Set publish_now: true to post immediately, scheduled_at to schedule, or omit both to save a draft you can edit and publish later.
• Accounts are connected first. Before the first post, connect accounts with POST /v1/social/connect (or the multi-platform POST /v1/social/portal) and POST /v1/social/sync — the equivalent of linking accounts through Ayrshare’s generateJWT URL.

​

Minimal viable migration

npm install @usenaive-sdk/server

​

Consolidate further once you’re on Naive

// The API key posts; the Profile Key scopes an Ayrshare-only identity.
const social = new SocialMediaAPI(process.env.AYRSHARE_API_KEY!);
await social.post({
  post: "Launch day!",
  platforms: ["twitter", "linkedin"],
  profileKeys: [process.env.ACME_PROFILE_KEY!],
});

// The card, inbox, phone, and KYC for this customer's agent live elsewhere —
// separate accounts, separate billing, separate audit — and "may this agent
// post?" is a key you hold, not a governed decision.

// One tenant user per customer; the same handle reaches every primitive.
const acme = await naive.users.create({
  external_id: dbCustomer.id,
  email: dbCustomer.email,
});

const client = naive.forUser(acme.id);

// Publishing is one primitive, gated + metered like the rest.
await client.social.createPost({
  content: "Launch day!",
  platforms: ["TWITTER", "LINKEDIN"],
  publish_now: true,
});

// The SAME client owns this customer's card, inbox, phone, and KYC — one
// account, one budget, one audit trail, every capability governed by its
// Account Kit.
await client.cards.create({ spending_limit_cents: 25_000 });
await client.email.createInbox({ local_part: "ops" });

​

Gain #1 — one account across primitives

• With Ayrshare, social posting is an island behind its own key and billing. With Naive, naive.forUser(acme.id) is a single handle to social and cards and email and phone and KYC — no second vendor account, no Profile Keys to provision and rotate, no separate invoice.
• Third-party connections (OAuth grants like Slack or Notion) and the agent’s native primitives sit under one identity and one Account Kit — the SaaS the agent connected and the networks it posts to, governed the same way.

​

Gain #2 — execution-time permission enforcement

• Whether an agent may post at all is the social primitive on the user’s Account Kit, decided at execution time — not a key you gate separately from everything else the agent can do.

// This tier's agents get email + cards, but cannot post to social at all.
const kit = await naive.accountKits.create({
  name: "No-social tier",
  primitives_config: {
    email: { enabled: true },
    cards: { enabled: true },
    social: { enabled: false }, // social calls are refused with `forbidden`
  },
});
await naive.accountKits.assignUser(kit.id, acme.id);

• The agent’s code path stays the same for every tier — client.social.createPost(...). Whether it runs is decided by policy: a user whose Account Kit does not enable social is refused with forbidden, with no code change on your side.
• Publishing spends 1 credit against the same budget ceiling as the agent’s cards, phone, and LLM calls — so a misbehaving agent trips one combined cap, not a separate Ayrshare limit you monitor on its own.

​

Gain #3 — unified accountability

• Every post records the acting agent and lands in one per-user activity log — alongside that customer’s card spend, email sends, and KYC events, not in a separate Ayrshare post history:

const { events } = await naive.forUser(acme.id).logs.query({ limit: 50 });
// "what did this agent do, for whom?" — social posts, card spend, email sends, one timeline

• That is the question that is hard to answer when posts live in Ayrshare, cards live in Stripe, and the inbox lives somewhere else. Under Naive it is a single query.

​

What does not map yet

​

Where to go next

• social primitive — full connect / post / schedule / analytics lifecycle, platform matrix, and platform defaults
• social SDK sub-client — typed listPosts / createPost
• social CLI — naive social connect / post per user
• Account Kits — enabling/disabling the social primitive per user at execution time
• Tenant users — the identity that owns social, cards, email, and phone
• Billing — the shared credit balance and budget ceiling publishing spends against
• Logs — the unified per-user activity trail every post lands in