█▀▄ █   ▄▀▄ ▀▄▀ ▄▀▄ █▀▄ █   █▀▀
█▀▄ █   █ █  █  █▀█ █▀▄ █   █▀
▀▀  ▀▀▀  ▀  ▀ ▀ ▀ ▀ ▀▀  ▀▀▀ ▀▀▀

platform apis · api.bloxable.app

Build with Bloxable from anywhere

Two public protocols expose the same infrastructure Bloxable's own agents use: a Records MCP for reading and writing workspace data from any MCP client, and a Hosting API for deploying static sites to {slug}.bloxable.app. Site auth is native — no external identity service required.

Records MCPQuery and write workspace tables over the Model Context Protocol Hosting APIDeploy static sites to {slug}.bloxable.app with one PUT Site authPer-user accounts, enforced server-side, zero config

Records MCP POST /mcp/records/{endpoint-id}

Ask your Bloxable agent to "create a data API for the leads table" — it returns an endpoint id (and a bearer token when writes are gated). Point any MCP client at:

https://api.bloxable.app/mcp/records/<endpoint-id>

Transport is streamable HTTP (JSON-RPC 2.0 over POST). Add Authorization: Bearer <token> when the endpoint requires it. Claude Code:

claude mcp add bloxable-records --transport http \
  https://api.bloxable.app/mcp/records/<endpoint-id> \
  --header "Authorization: Bearer <token>"

tool	arguments	behavior
`describe`	—	table, allowed operations, access model
`query_records`	`where?` `order_by?` `desc?` `limit?` `id?`	returns `{ ok, rows }`; empty table → `rows: []`
`create_record`	`data`	keys must match columns; id/created_at automatic
`update_record`	`id`, `data`	changed fields only
`delete_record`	`id`

Every call passes through the endpoint's own permission layer — allowed operations, rate limits, and per-user row scoping are enforced server-side. MCP cannot escalate past them.

Hosting API PUT · GET · DELETE /v1/sites/{slug}

Auth: ask your agent for a platform key ("create a platform API key labeled CI") — you'll get a bxk_… key, shown once. Revoke it anytime by asking the agent to delete it.

# deploy (create or update)
curl -X PUT https://api.bloxable.app/v1/sites/my-site \
  -H "Authorization: Bearer $BLOXABLE_KEY" \
  -H "content-type: application/json" \
  -d '{"files":[{"path":"index.html","content":"<!doctype html>…"}]}'

index.html required; relative paths only. html/css/js/svg/json/images; ≤60 files, ≤4 MB. Binary files: "encoding":"base64".
Slugs are global, lowercase [a-z0-9-]. Your deploys own their slugs; re-PUT to update. Another workspace's slug → error.
The response is honest: { ok: true, url, verified: true } means the deployment was fetched and confirmed serving. Fresh custom domains can take a minute or two of DNS.
GET /v1/sites/{slug} → status · DELETE /v1/sites/{slug} → tears down hosting, DNS, and the registry entry.

Site auth — native {data-api}/auth

Data APIs created with auth: "user" grow a real account system:

POST {url}/auth  {"action":"signup","email":"…","password":"…"}  → { token, user }
POST {url}/auth  {"action":"login", "email":"…","password":"…"}  → { token, user }
GET  {url}       (Authorization: Bearer <session>) → only that user's rows

Ownership is enforced in the database layer — shipping the endpoint URL in client code is safe by design, and there is never a shared secret in the browser. Use an external identity provider only if you need third-party SSO (Google/GitHub), SAML, or MFA.

Bloxable · this page is deployed through the Hosting API it documents.