Quickstart
This reference documents the path from initial operator credentials to a first authenticated call verified in the audit chain. The five steps below correspond to five verifiable artefacts.
Obtain operator credentials
Every request to the Nebbos platform is authenticated with a Bearer token issued to a specific operator identity. Operator credentials are provisioned by the deployment administrator against a sandbox or production tenant. The identity carries the operator’s tier assignment (Guest, Host, or Architect) and the departments within its scope.
Enrol a Cradle if the target tier requires it
Guest-tier reads clear on the device-native biometric. Host-tier writes require a Cradle physically present at the time of the call. Architect-tier administrative operations require an additional enclave-signed approval token. Integrations that operate above the Guest tier follow the Cradle provisioning path prior to first call.
Discover the MCP surface
The first call from an integration is list_available_tools. This returns the current tool roster, input schemas, and per-tool tier requirements. Integrations should pin against the discovered roster rather than a hard-coded list, so that additions to the surface become available on the next discovery pass without integration code changes.
Python
from nebbos import Client
client = Client(token="nbbs_...")
tools = client.mcp.list_available_tools()
for t in tools:
print(t.name, "→", t.tier_required)Execute the first authenticated call
Select a read-tier tool from the discovery response (for example, get_context, list_departments, or describe_pearl). The call succeeds when the Bearer token is valid and the operator’s scope covers the target. Refusals include the specific policy identifier responsible for the refusal; the platform does not return generic authorisation errors.
curl -sS https://api.nebbos.ai/api/v1/departments \
-H "Authorization: Bearer $NEBBOS_TOKEN"Verify recording in the audit chain
The preceding call produces one entry in the hash-chained audit log. The entry is retrievable through audit_event_list, filtered by operator identity and time window. Each entry includes tool name, input hash, output hash, tier, and the chain hash. Chain entries constitute the audit-preparation evidence a compliance officer requires.
curl -sS "https://api.nebbos.ai/api/v1/audit/events?since=5m" \
-H "Authorization: Bearer $NEBBOS_TOKEN" \
| jq '.events[] | {tool, tier, outcome, input_hash}'Platform-provided services
Integrations do not provision an independent database, identity provider, or audit pipeline. Every Nebbos deployment provides row-level isolation at the substrate, a shared hash-chained audit log, and the WorkOS-mediated identity plane. Integration work consists of consuming these services rather than reproducing them.
Next references
- Authentication & tiers — the three-tier gate and authentication artefacts.
- MCP reference — capability categories and discovery pattern.
- The audit chain — verification receipt structure and independent verification path.