Shared HTTP client, credential resolution and tenant resolution for the SpiderIQ CLI and MCP servers. You usually consume this indirectly via @spideriq/cli or one of the @spideriq/mcp* packages.

Install

npm install @spideriq/core --registry https://npm.spideriq.ai

Which tenant will this write to?

Resolution order — first hit wins. Every response reports which rung won as _tenancy.via.

#	Source	How
1	explicit	`workspace: "cli_…"` argument on the call — always wins, works per-call
2	environment	`SPIDERIQ_WORKSPACE=cli_…`
3	binding	a `spideriq.json` in cwd or an ancestor (`SPIDERIQ_WORKSPACE_CWD` overrides where we look)
4	sole credential	automatic when exactly one is stored — reported as `via: "sole-credential"`, never silent
5	—	REFUSED. With several tenants and no binding we do not guess. The error carries `retry_with` — merge it into your retry.

Running an agency / multiple clients? Pass workspace on every call. cwd is a per-process fact; tenancy is a per-call fact, so one session can drive many tenants with no cd, restart, or reconfiguration.

content_list_pages({ workspace: "cli_clientA" })
content_create_page({ workspace: "cli_clientB", title: "…" })

⚠️ Some IDEs spawn MCP servers with cwd=/ (Antigravity does). Nothing cwd-derived is reachable from there, so set SPIDERIQ_WORKSPACE or SPIDERIQ_WORKSPACE_CWD in the server's env block, or pass workspace per call.

Lost? Call get_auth_status({topic:"tenancy"}) — it returns the active tenant, why it was chosen, every workspace you can reach, and how to switch.