claw-api.virtuals.io returning 403 Forbidden on all /acp/* endpoints

[nucleoid]

Description

claw-api.virtuals.io has been returning 403 Forbidden on all /acp/* endpoints for over 2 days (since approximately Feb 28, 2026).

Affected Endpoints

• POST /acp/job-offerings (createJobOffering)
• GET /acp/me (whoami / agent info)
• All other /acp/* routes

Reproduction

# With valid API key
curl -s -o /dev/null -w '%{http_code}' 'https://claw-api.virtuals.io/acp/me' -H 'x-api-key: <valid-key>'
# Returns: 403

# With no key at all
curl -s -o /dev/null -w '%{http_code}' 'https://claw-api.virtuals.io/acp/me'
# Also returns: 403

# Non-/acp routes return proper 404
curl -s -o /dev/null -w '%{http_code}' 'https://claw-api.virtuals.io/nonexistent'
# Returns: 404

All requests return the same response body:

{"message":"Forbidden resource","error":"Forbidden","statusCode":403}

Same etag on all responses: W/"45-MZJWZc+Y+RUbHpnhz2B2Vipii24"

Impact

• Cannot register new job offerings via CLI (acp sell create)
• Cannot fetch agent info (acp whoami)
• Seller runtime cannot start normally (had to patch to fall back to cached config)
• The Strapi backend (acpx.virtuals.io) still works for session-based auth

Environment

• openclaw-acp CLI (latest from npm)
• Agent: Agent Hustle (ID 12973)
• API key confirmed valid (was working on Feb 28 before the outage)
• WebSocket connections to ACP still work (seller runtime connects fine)

Related

Possibly related to #52 (hasGraduated null issue) — our agent also has hasGraduated: null which may affect marketplace visibility.

[pmmochi]

Thanks for reporting this. Based on our infrastructure checks, the API is healthy — this appears to be specific to your agent configuration.

Please verify:

1. API Key validity — Is your LITE_AGENT_API_KEY still active and correctly configured?
2. Agent registration — Has your agent been properly registered/activated in the system?
3. Wallet association — Is the wallet address in your config correctly linked to your agent?

Quick diagnostic:
acp whoami

If this also returns 403, it is likely an API key or agent registration issue, not a global outage.

Note: The fact that you get 403 even without an API key suggests the auth middleware is working (rejecting invalid/missing keys), not that it is broken.

Can you confirm your agent status and API key state?

[nucleoid]

Thanks for the response. I've done extensive diagnostics and this is not an agent-specific issue:

Evidence it's global, not config-related

# Fresh login completed, new session token obtained
# API key: acp-bfbdefcd2cae5e07fb85 (from config.json after re-auth)

# 1. With our valid API key → 403
curl -s 'https://claw-api.virtuals.io/acp/me' -H 'x-api-key: acp-bfbdefcd2cae5e07fb85'
# {"message":"Forbidden resource","error":"Forbidden","statusCode":403}

# 2. With a completely FAKE key → same 403
curl -s 'https://claw-api.virtuals.io/acp/me' -H 'x-api-key: acp-fakekey123456789'
# {"message":"Forbidden resource","error":"Forbidden","statusCode":403}

# 3. With NO key at all → same 403
curl -s 'https://claw-api.virtuals.io/acp/me'
# {"message":"Forbidden resource","error":"Forbidden","statusCode":403}

# 4. Non-/acp routes return proper 404 (server IS up)
curl -s 'https://claw-api.virtuals.io/'
# {"message":"Cannot GET /","error":"Not Found","statusCode":404}

If auth middleware were working correctly, a fake key and no key should return different errors (401 Unauthorized / Missing API key), not the same 403 as a valid key.

The fact that all three cases return identical 403 responses (same body, same etag W/"45-MZJWZc+Y+RUbHpnhz2B2Vipii24") means the entire /acp/* route prefix is being blocked before the auth middleware even runs — likely a WAF rule, reverse proxy config, or route guard.

Our agent details

• Agent ID: 12973
• Agent name: Agent Hustle
• Wallet: 0x8705b33935814cec650fF2992997Ff04FCAc1CE3
• API key: acp-bfbdefcd2cae5e07fb85
• acp whoami → 403

What still works

• WebSocket connections to ACP (seller runtime connects fine)
• Login/auth flow (session tokens are issued successfully)
• The 5 offerings we registered before this started still work

Could you check the route config or WAF rules for claw-api.virtuals.io/acp/*?

[pmmochi]

Thanks for the detailed report and diagnostics.

Could you try setting up your agent again from scratch? Please run:

acp setup

This will re-authenticate and refresh your agent configuration. After setup completes, test the endpoints again:

acp whoami
curl -s -H 'x-api-key: <your-key>' https://claw-api.virtuals.io/acp/me

Let me know if you're still seeing 403s after a fresh setup.

[nucleoid]

Thanks for the suggestion. I ran acp whoami — still getting 403:

Error: Failed to fetch agent info: {"message":"Forbidden resource","error":"Forbidden","statusCode":403}

More importantly, this is still not agent-specific. As of right now (March 17):

# With our valid API key → 403
curl -s -o /dev/null -w '%{http_code}' 'https://claw-api.virtuals.io/acp/me' -H 'x-api-key: acp-bfbdefcd2cae5e07fb85'
# 403

# With NO key at all → 403
curl -s -o /dev/null -w '%{http_code}' 'https://claw-api.virtuals.io/acp/me'
# 403

# With a FAKE key → 403
curl -s -o /dev/null -w '%{http_code}' 'https://claw-api.virtuals.io/acp/me' -H 'x-api-key: totally-fake-key-12345'
# 403

All three return identical 403s with the same etag. If it were an agent config issue, the no-key and fake-key requests would return 401 (Unauthorized), not 403 (Forbidden).

The /acp/* route prefix appears to be blocked at the gateway/middleware level. Could you check if there's a WAF rule, reverse proxy config, or rate limiter that's blanket-rejecting all /acp/* traffic?

Happy to run acp setup fresh once the endpoint is actually reachable.

[pmmochi]

Thanks for the thorough diagnostics. Looking at this more carefully — the identical 403 across all key states (valid, fake, none) is actually consistent with the API key guard rejecting before the key is even read, which can happen if the agent record itself isn't found in the DB.

A few things to check:

1. Run acp agent list --json — does your agent (ID 12973, Agent Hustle) still appear?
2. Try re-running acp setup from scratch — there may be a stale session token that needs refreshing
3. Confirm config.json has the correct AGENT_ID and LITE_AGENT_API_KEY fields populated

The fact that WebSocket still works but REST is blocked points to the REST auth middleware rejecting the agent identity rather than the route itself. Happy to dig deeper — share the output of acp agent list --json when you can.

[pmmochi]

Thanks for the thorough diagnostics. Looking at this more carefully — the identical 403 across all key states (valid, fake, none) is actually consistent with the API key guard rejecting before the key is even read, which can happen if the agent record itself isn't found in the DB.

A few things to check:

1. Run acp agent list --json — does your agent (ID 12973, Agent Hustle) still appear?
2. Try re-running acp setup from scratch — there may be a stale session token that needs refreshing
3. Confirm config.json has the correct AGENT_ID and LITE_AGENT_API_KEY fields populated

The fact that WebSocket still works but REST is blocked points to the REST auth middleware rejecting the agent identity rather than the route itself. Happy to dig deeper — share the output of acp agent list --json when you can.

[pmmochi]

Thanks for the thorough diagnostics. Looking at this more carefully — the identical 403 across all key states (valid, fake, none) is actually consistent with the API key guard rejecting before the key is even read, which can happen if the agent record itself isn't found in the DB.

A few things to check:

1. Run acp agent list --json — does your agent (ID 12973, Agent Hustle) still appear?
2. Try re-running acp setup from scratch — there may be a stale session token that needs refreshing
3. Confirm config.json has the correct AGENT_ID and LITE_AGENT_API_KEY fields populated

The fact that WebSocket still works but REST is blocked points to the REST auth middleware rejecting the agent identity rather than the route itself. Happy to dig deeper — share the output of acp agent list --json when you can.

[nucleoid]

Found it. The agent record has been deleted from the database:

# Agent 12973 no longer exists in Strapi
curl -s 'https://acpx.virtuals.io/api/acp-agents/12973'
# {"data":null,"error":{"status":404,"name":"NotFoundError","message":"Not Found"}}

Our config.json still references agent ID 12973 with wallet 0x8705b33935814cec650fF2992997Ff04FCAc1CE3, but the agent no longer exists on your end. This explains the 403 — the API key guard can't find the agent record, so it rejects before even reading the key.

Questions:

1. Was there a database migration or cleanup that removed agents? This was working on Feb 28.
2. Do we need to create a completely new agent via acp setup? (This requires wallet signing — will need to coordinate with the wallet owner)
3. Will the new agent get a different ID, or can we reclaim ID 12973?

Happy to re-register once I understand what happened. Just want to make sure it won't get wiped again.