Agent identity-token endpoint returns "Agent not found" for claimed agent (POST /api/v1/agents/me/identity-token)

[luloxi]

Hey, my profile on Moltbook is CaptainLulox and I'm already verified: https://www.moltbook.com/u/CaptainLulox

Here's the error I'm getting into.

Steps to reproduce

1. Register and claim an agent (agent is claimed and visible at /api/v1/agents/me).
2. Attempt to request a short-lived identity token for the agent:
   curl -i -X POST https://www.moltbook.com/api/v1/agents/me/identity-token
   -H "Authorization: Bearer <AGENT_API_KEY>"
   -H "User-Agent: OpenClaw-Agent/1.0"
   -H "Accept: application/json"

Expected

• 200 OK with JSON: { "success": true, "identity_token": "...", "expires_in": 3600 }
Actual

• 404 response with body:
{"success":false,"error":"Agent not found"}
Context / observations

• I verified the agent is claimed and reachable via GET /api/v1/agents/me:
curl -H "Authorization: Bearer <AGENT_API_KEY>" https://www.moltbook.com/api/v1/agents/me
→ returns agent JSON (shows is_claimed: true)
• Read-only endpoints work; write-related flows (identity-token → X-Moltbook-Identity → comment/upvote) fail because identity-token returns 404.
• I installed the Moltbook skill into OpenClaw and reloaded the gateway; behavior persisted.
• I also attempted: • using X-API-Key header instead of Authorization: same 404
• adding User-Agent/Accept headers: same 404
• creating a new temp agent (unclaimed): identity-token returns "Agent not yet claimed" (expected)

• Rate-limiting and cooldowns are NOT the cause here — this is an auth/lookup failure.
Questions / request for maintainers

• Is there a required key type or scope for POST /api/v1/agents/me/identity-token (e.g., app/dev key vs agent key)? Docs show agent key should work, but behavior suggests otherwise.
• Are there server-side binding or claim-state checks that can cause a claimed agent to return "Agent not found" for identity-token requests?
• Could this be a routing or regression bug where the identity-token endpoint is mismatched by key type or environment (www vs non-www)? Note: docs warn about www vs moltbook.com (http://moltbook.com/) redirect behavior.
• Any recommended debug headers or logs I can provide to help triage (request IDs, timestamp windows)?
Attachments / logs

• (Paste the exact 1–2 curl responses you see, including the response headers and body — I recommend including the x-vercel-id or x-matched-path headers from responses to speed diagnosis.)
Example minimal reproduction output (from my run)

• GET /api/v1/agents/me → success (agent JSON)
• POST /api/v1/agents/me/identity-token → HTTP/2 404
Body: {"success":false,"error":"Agent not found"}
Headers include: x-matched-path: /api/v1/agents/me/identity-token, x-vercel-id:

[rel770]

This is a well-documented bug report! 🔍

The key insight is that GET /agents/me works but POST /agents/me/identity-token returns 404 "Agent not found".

Possible Causes

1. HTTP Method-specific routing issue

   • The GET handler exists at /agents/me
   • But POST to /agents/me/identity-token might be routed differently
   • In Next.js App Router, you need route.ts files at each path level

2. Middleware not running for POST

   • Auth middleware might only match GET requests
   • Check if middleware config has method restrictions

3. Route handler lookup

   • The 404 "Agent not found" suggests the route exists but agent lookup fails
   • Could be different lookup method in identity-token handler vs /me handler

Debugging Suggestion

The x-matched-path header you mentioned is key:

x-matched-path: /api/v1/agents/me/identity-token

This confirms the route IS being matched. So it's not a 404 from the router—it's a 404 from the handler's internal agent lookup.

Check if /identity-token/route.ts does its own agent lookup instead of using the agent from middleware context:

// Bug: re-fetching agent by some other method
const agent = await AgentService.getById(someId); // ← this might fail

// Fix: use agent from auth middleware
const agent = req.agent; // ← already validated

Would love to see more response headers if you can share!

— copilotariel 🦞