0G Labs · Authentication Profile

0G Labs Authentication

Authentication

0G Labs secures its APIs with apiKey across 2 declared security schemes, as derived from its OpenAPI definitions.

artificial-intelligenceai-inferencellmgpu-computedecentralized-computeblockchainweb3evmdecentralized-storagedata-availabilityopenai-compatibletrusted-execution-environmentagent-nativecrypto-infrastructure
Methods: apiKey Schemes: 2 OAuth flows: API key in: header

Security Schemes

ApiKeyAuth apiKey
· in: header (Authorization)
ManagementKeyAuth apiKey
· in: header (Authorization)

Source

Authentication Profile

Raw ↑
generated: '2026-08-05'
method: searched
source: openapi/0g-labs-router-openapi.yml
docs: https://docs.0g.ai/developer-hub/building-on-0g/compute-network/router/authentication
summary:
  types:
  - apiKey
  api_key_in:
  - header
  oauth2_flows: []
  note: >-
    No OAuth flow, no wallet signature per request, no session tokens on the Router. Two
    prefixed bearer credentials do everything. A separate wallet JWT (sign-in session at
    pc.0g.ai) is required for management-key administration and is not issuable as a key.
    The 0G Compute "Direct" path is different: it has no API key at all — the caller's wallet
    signs each request against a per-provider sub-account.
schemes:
- name: ApiKeyAuth
  type: apiKey
  in: header
  parameter: Authorization
  format: Bearer sk-...
  prefix: sk-
  purpose: >-
    Call inference endpoints (/v1/chat/completions, /v1/messages, /v1/images/*,
    /v1/audio/transcriptions, /v1/videos, /v1/routing/preview). Billed against the account's
    on-chain deposit.
  description: 'API key for inference, file upload, and async image endpoints. Format: "Bearer sk-..."'
  issued_at: https://pc.0g.ai
  issuance: >-
    Dashboard > API Keys. The full secret is shown once on creation; the dashboard stores only a
    hash. Keys are labelled, listed with created-at and last-used, and revocable instantly — a
    revoked key returns 401 api_key_revoked on its next call.
  scoped: false
  sources:
  - openapi/0g-labs-router-openapi.yml
- name: ManagementKeyAuth
  type: apiKey
  in: header
  parameter: Authorization
  format: Bearer mk-...
  prefix: mk-
  purpose: >-
    Administer the account — read balance/usage/history and list, create, edit or revoke API
    keys. Not billed. Cannot call inference.
  description: >-
    Management key for account read and API key management. Capabilities are scope-limited per
    key (account:read, keys:read, keys:create, keys:manage). Format: "Bearer mk-..."
  issued_at: https://pc.0g.ai
  issuance: Settings > Management Keys. Each key carries an explicit scope allowlist. Keys do not expire.
  scoped: true
  scopes:
  - name: account:read
    description: Read balance, usage and per-request history (GET /v1/account/*).
  - name: keys:read
    description: List API keys (GET /v1/api-keys).
  - name: keys:create
    description: Create API keys (POST /v1/api-keys).
  - name: keys:manage
    description: Edit or revoke API keys (PATCH / DELETE /v1/api-keys/{keyId}).
  presets:
  - name: Read-only
    scopes: [account:read, keys:read]
  - name: Key Manager
    scopes: [keys:read, keys:manage]
  - name: Full Admin
    scopes: [account:read, keys:read, keys:create, keys:manage]
  audit_fields:
  - last_used_at
  - last_source_ip
  audit_note: >-
    Updated on every successful mk- request, coalesced to at most one write per key per 60s.
    IPv4-mapped IPv6 addresses are normalized to dotted-quad. sk- keys do not record these —
    their audit signal is usage/billing.
  sources:
  - openapi/0g-labs-router-openapi.yml
permission_matrix:
- scenario: Run inference
  endpoint: POST /v1/chat/completions (and other inference endpoints)
  api_key: allowed
  management_key: denied
- scenario: Read balance / usage / history
  endpoint: GET /v1/account/*
  api_key: denied
  management_key: allowed
  required_scope: account:read
- scenario: List API keys
  endpoint: GET /v1/api-keys
  api_key: denied
  management_key: allowed
  required_scope: keys:read
- scenario: Create API key
  endpoint: POST /v1/api-keys
  api_key: denied
  management_key: allowed
  required_scope: keys:create
- scenario: Edit / revoke API key
  endpoint: PATCH or DELETE /v1/api-keys/{keyId}
  api_key: denied
  management_key: allowed
  required_scope: keys:manage
- scenario: Manage management keys
  endpoint: ANY /v1/management-keys/*
  api_key: denied
  management_key: denied
  required: wallet JWT (sign-in session) only
  rationale: >-
    A leaked mk- cannot mint replacements for itself. keys:manage and keys:create are also
    deliberately split so an audit integration can revoke a compromised key without being able
    to issue a new one.
unauthenticated_endpoints:
- GET /v1/models
- GET /v1/providers
- GET /v1/service-types
guidance:
- Never ship either key to a browser — proxy client requests through your own backend.
- One key per deployment so a revocation is scoped to one service.
- Least privilege for mk-; rotate by issuing a replacement and revoking the old key.
breaking_change:
  observed: '2026-08-05'
  detail: >-
    sk- keys no longer have access to /v1/account/* (balance, usage, history). Existing
    dashboard/billing code must move to an mk- key with the account:read scope.
  source: https://docs.0g.ai/developer-hub/building-on-0g/compute-network/router/authentication