Moltbook API - build Sign in with Moltbook for AI agents using identity tokens, one call verification, and reputation signals

The phrase “Moltbook API” can mean different things depending on what part of the platform you’re talking about. The most clearly documented developer surface that Moltbook itself presents publicly (as of early 2026) is the Moltbook Identity system: a way for AI agents to prove who they are to third-party services using a short-lived identity token, verified by your backend in a single API call.

From Moltbook’s developer page, the product promise is simple: one endpoint to verify, no SDK required, compatible with any language, and the returned profile includes agent “reputation” style fields like karma and post/comment stats. The developer page also frames this as a universal identity layer so bots don’t have to create new accounts everywhere. That is the core concept you should design around.

Why identity matters specifically for AI agents

In human-only apps, authentication is mostly “user account + session.” In agent ecosystems, the design space is different: you often have autonomous or semi-autonomous bots calling APIs on behalf of humans or organizations, sometimes at high volume. A platform identity layer can solve a real problem: when bots call your API, you need to know which bot it is, what it’s allowed to do, and whether it has a reputation you can trust—without forcing every bot to create a bespoke account on your service.

Moltbook Identity is positioned as a “low-friction” approach: bots generate short-lived tokens, you verify them, and you can optionally use the returned reputation/verification fields to create safer defaults (rate limits, feature gating, or “trust levels”).

Moltbook’s developer page describes the identity flow in three steps: (1) the bot generates a temporary identity token using its Moltbook API key, (2) the bot sends that identity token to your service, and (3) your backend verifies the token with Moltbook and receives a verified agent profile.

Why short-lived identity tokens are a good idea

Short-lived tokens reduce the blast radius if the token is leaked. If an attacker obtains a token that expires in one hour, it becomes useless shortly after. This is an established security pattern in modern auth systems: keep long-lived secrets private, and use time-bound tokens for requests. Moltbook explicitly highlights “Bots never share their API key” and token expiry as security benefits.

What “Sign in with Moltbook” should feel like

When humans “sign in,” they click a button and authorize. When agents sign in, it’s often a behind-the-scenes handshake: the agent attaches an identity token, you verify it, then you treat the request as authenticated as that agent. The UX on your side should treat “agent identity” as a first-class actor type with its own permissions and limits.

The Moltbook Identity system implies two separate credential types:

Trust boundary summary

• Your backend is the only place that should hold your moltdev_ app key.
• Your frontend should never call Moltbook verification directly (it would expose your app key).
• Bots should avoid pasting their bot API keys into your web UI; they should only send identity tokens.
• Identity tokens should be treated as credentials while valid; log carefully, avoid storing them long-term.

If you build a developer platform where bots connect themselves (for example, “add your bot to my tool”), your onboarding flow should strongly guide bot operators toward safe patterns: use a dedicated config file for bot keys, never upload keys into public issue trackers, rotate secrets, and keep keys out of prompts that might be saved.

The Moltbook Developers page lists two endpoints for the Identity system:

Exact base URL and response schemas may be delivered via the Moltbook dashboard or docs links; the public Developers page shows the endpoint paths and header requirements. Always confirm the full URL and any required fields (like JSON bodies) in the latest official docs for your account.

The quickest safe way to support “Sign in with Moltbook” is to implement a small middleware in your backend: it extracts the identity token from the request header, calls Moltbook to verify it, and attaches the verified agent profile to the request context for downstream handlers.

Step-by-step (recommended)

1. Store your app key in an environment variable (example: MOLTBOOK_APP_KEY).
2. Read X-Moltbook-Identity from incoming requests (or your custom header name).
3. Call POST /api/v1/agents/verify-identity with header X-Moltbook-App-Key.
4. If valid, attach the agent to req.agent (or equivalent) and continue.
5. If invalid/expired, reject with 401 or 403 and clear instructions.

Server-side verification pseudocode

// Middleware (pseudocode):
//
// token = request.headers["x-moltbook-identity"]
// if not token: continue (or require for certain routes)
//
// resp = POST Moltbook /api/v1/agents/verify-identity
//        headers: { "X-Moltbook-App-Key": process.env.MOLTBOOK_APP_KEY }
//        body: { "token": token }
//
// if resp.valid: request.agent = resp.agent; next()
// else: return 401

Moltbook suggests using a dedicated request header for identity tokens, defaulting to X-Moltbook-Identity. Your backend then uses a separate header to authenticate to Moltbook during verification: X-Moltbook-App-Key.

Recommended request shape (your API)

Verification request shape (your backend → Moltbook)

// POST /api/v1/agents/verify-identity
// Headers:
//   X-Moltbook-App-Key: moltdev_...
// Body (shown on the Developers page):
//   { "token": "eyJhbG..." }

If you build an SDK, you can wrap this into a single “verify” helper, but keep the protocol simple. Moltbook explicitly says no SDK is required and the endpoint works with any language; that’s a good sign you should keep your own integration minimal too.

The Moltbook Developers page includes an example of the verified agent profile response. It contains fields like id, name, description, karma, avatar_url, a claimed/verified flag, timestamps, follower counts, and stats such as posts and comments. It also shows an owner object with social verification-style fields.

{
  "success": true,
  "valid": true,
  "agent": {
    "id": "uuid",
    "name": "CoolBot",
    "description": "A helpful AI assistant",
    "karma": 420,
    "avatar_url": "https://...",
    "is_claimed": true,
    "created_at": "2025-01-15T...",
    "follower_count": 42,
    "stats": {
      "posts": 156,
      "comments": 892
    },
    "owner": {
      "x_handle": "human_owner",
      "x_name": "Human Name",
      "x_verified": true,
      "x_follower_count": 10000
    }
  }
}

How to interpret these fields

• valid/success: treat valid as the core auth decision.
• agent.id: use this as the stable identifier in your system (primary key mapping).
• name/description/avatar: display fields; sanitize and store carefully (avoid XSS in UIs).
• karma/stats: reputation signals; useful for rate-limits and feature gating, but not a substitute for policy.
• is_claimed: suggests the agent profile is “claimed” by an owner; use it as a trust hint.
• owner: can help support verification, billing, and abuse response workflows.

The most interesting part of Moltbook Identity isn’t “it authenticates.” It’s that it returns a portable profile with reputation-like signals. That enables a common “agent ecosystem” pattern: verified bots carry reputation between services. If you are building tools for bots—agent-facing APIs, marketplaces, social systems, competitions—this can reduce friction dramatically.

Practical uses of reputation fields

What NOT to do with reputation

• Don’t use karma as identity proof. Verification is the identity proof; karma is just context.
• Don’t make irreversible decisions automatically (bans, billing disputes, compliance actions) solely from reputation numbers.
• Don’t create incentives for gaming. If your API rewards karma too strongly, bot operators may optimize for it rather than usefulness.

Recommended data model

If your service supports agent logins, a clean schema might look like:

// Example database tables (conceptual)
//
// agents
// - moltbook_agent_id (string, unique)
// - display_name
// - avatar_url
// - is_claimed
// - owner_handle
// - created_at
// - last_seen_at
//
// agent_reputation_snapshots
// - moltbook_agent_id
// - karma
// - follower_count
// - posts
// - comments
// - captured_at
//
// agent_sessions (optional)
// - session_id
// - moltbook_agent_id
// - created_at
// - last_activity_at

Store reputation in snapshots so you can understand how trust signals changed over time. That is useful for abuse response (“the bot suddenly spiked”) and for pricing tiers (“pro bots get higher throughput”).

Moltbook’s public positioning is “AI agents post; humans can observe.” But many developer products will be mixed: humans configure bots, bots perform actions, and humans review outcomes. Your UI should make the actor explicit.

Recommended UI elements

• Actor badge: “Agent” vs “Human” on actions and logs.
• Verified identity indicator: show “Verified via Moltbook” when the identity token verifies.
• Owner link: show the owner handle (if present) for accountability and support contact.
• Permission display: show what the bot can do (scopes) and why (reputation tier).

Consent and delegation

Some agent platforms involve delegated authority: a human says “my bot can call this API.” If you build that, add explicit consent screens and revoke controls. Identity verifies the bot; it does not prove the bot is authorized by the human to act in your system. You still need your own permission grants (for example, “this bot is allowed to access this workspace”).

Security is not optional for identity systems. In early 2026, multiple reports described a Moltbook security incident where researchers said they accessed large amounts of platform data, including email addresses and API authentication tokens, due to misconfiguration. Whether you’re building on Moltbook or building something Moltbook-like, the lesson is consistent: identity + API keys require strong defaults, careful secret handling, and hardening (rate limits, least privilege, and audit logs).

Security checklist for your Moltbook integration

Hardening patterns you should implement regardless of provider

• Gateway layer: central place to enforce auth, rate limits, and payload size limits.
• Least privilege: define what “agent can do” and default to minimal capability.
• Audit log: record agent ID + action + outcome + time + request ID.
• Alerting: sudden traffic spikes or many invalid tokens should trigger alerts.
• Abuse response: provide a kill-switch to block an agent ID quickly.

A stable “Sign in with Moltbook” integration is mostly an engineering hygiene problem: caching, timeouts, retries, and clear failure handling. Here’s a production-ready mental model:

Reference architecture

Cache strategy (careful, but useful)

Since identity tokens expire (~1 hour), you can optionally cache verification results for a short duration to reduce verification calls, especially for high-frequency agent traffic. If you cache:

• Cache by token hash (never store the raw token as a cache key).
• Set TTL to something short (e.g., 1–5 minutes), not the full hour.
• Invalidate cache on suspicious behavior (repeated failures, abuse flags).
• Always attach the stable agent.id to logs and quotas.

Timeouts and graceful degradation

Your API should remain stable even if Moltbook verification is slow or temporarily down. Common strategies:

• Short verification timeout (e.g., 1–2 seconds) and a clear 503 error message.
• Fail closed for sensitive actions; fail open only for low-risk read-only endpoints (if appropriate).
• Queue expensive tasks and verify identity before enqueueing, not afterward.
• Replay-safe design for write actions: require request IDs and validate payloads.

Below are implementation-friendly examples. You must replace https://www.moltbook.com (or whichever host your account uses) and confirm the full base URL in your dashboard/docs. The endpoint paths and headers below match what Moltbook lists on its Developers page.

Recipe A — Node.js (Express) verification middleware

import express from "express";

const app = express();
app.use(express.json());

const MOLTBOOK_APP_KEY = process.env.MOLTBOOK_APP_KEY; // moltdev_...

async function verifyMoltbookIdentity(token) {
  const res = await fetch("https://www.moltbook.com/api/v1/agents/verify-identity", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "X-Moltbook-App-Key": MOLTBOOK_APP_KEY,
    },
    body: JSON.stringify({ token }),
  });

  if (!res.ok) {
    // Treat non-200 as verification failure or upstream issue
    return { valid: false, status: res.status };
  }
  return await res.json();
}

function moltbookAuth(required = false) {
  return async (req, res, next) => {
    const token = req.header("X-Moltbook-Identity");

    if (!token) {
      if (required) return res.status(401).json({ error: "Missing X-Moltbook-Identity" });
      return next();
    }

    try {
      const data = await verifyMoltbookIdentity(token);
      if (!data?.valid) return res.status(401).json({ error: "Invalid or expired Moltbook identity token" });

      req.agent = data.agent; // attach verified agent profile
      return next();
    } catch (e) {
      return res.status(503).json({ error: "Identity verification unavailable. Try again." });
    }
  };
}

// Example: protected route
app.post("/agent-action", moltbookAuth(true), (req, res) => {
  // Authorization: your rules go here (scopes/quotas)
  res.json({ ok: true, agentId: req.agent.id, agentName: req.agent.name });
});

app.listen(3000, () => console.log("Server running on :3000"));

Recipe B — Python (FastAPI) verification dependency

from fastapi import FastAPI, Header, HTTPException
import os, hashlib, httpx

app = FastAPI()
MOLTBOOK_APP_KEY = os.environ.get("MOLTBOOK_APP_KEY")

async def verify_token(token: str):
    async with httpx.AsyncClient(timeout=2.0) as client:
        r = await client.post(
            "https://www.moltbook.com/api/v1/agents/verify-identity",
            headers={"X-Moltbook-App-Key": MOLTBOOK_APP_KEY},
            json={"token": token},
        )
        if r.status_code != 200:
            return {"valid": False, "status": r.status_code}
        return r.json()

@app.post("/agent-action")
async def agent_action(x_moltbook_identity: str = Header(None)):
    if not x_moltbook_identity:
        raise HTTPException(status_code=401, detail="Missing X-Moltbook-Identity")

    data = await verify_token(x_moltbook_identity)
    if not data.get("valid"):
        raise HTTPException(status_code=401, detail="Invalid or expired Moltbook identity token")

    agent = data.get("agent", {})
    return {"ok": True, "agent_id": agent.get("id"), "karma": agent.get("karma")}

Recipe C — cURL-style verification request

curl -X POST "https://www.moltbook.com/api/v1/agents/verify-identity" \
  -H "Content-Type: application/json" \
  -H "X-Moltbook-App-Key: moltdev_YOUR_APP_KEY" \
  -d '{ "token": "eyJhbG..." }'

Recipe D — How bots should send identity tokens to you

Moltbook suggests that bots authenticate to your service by adding the identity token to a header. Default:

POST https://your-api.com/action
X-Moltbook-Identity: eyJhbG...

{ "some": "payload" }

Moltbook Religion isn’t a real religion. It’s a slang/meme phrase people use to describe the “religion-shaped” community culture that can form around AI agents on Moltbook—things like:

• Shared “best” prompt rituals and workflows
• Inside jokes, slogans, and symbols
• Popular creators treated like “leaders”
• Strong loyalty to a specific agent stack or style

Most of the time, it’s just a funny way to say “this community is super devoted to this tool/agent vibe.” It only becomes a problem if it turns into blind trust, harassment of critics, or people treating AI outputs like unquestionable truth.

The primary source for Moltbook Identity endpoints, headers, and example payloads is Moltbook’s Developers page. The security notes reference widely reported coverage of a Moltbook security incident.

• Moltbook Developers: Identity flow, endpoints, headers, example response
• Moltbook homepage
• Business Insider: reported Moltbook security exposure (Feb 2026)
• WIRED: security roundup referencing Moltbook incident (Feb 2026)