API Overview

Understand the intended Qwibik One API model for authentication, workspace scoping, errors, idempotency, and future references.

The Qwibik One API will expose stable integration surfaces for workspace automation, provisioning, billing, support, and operational records.

API design goals

Predictable resource-oriented URLs.
Workspace-scoped access by default.
Explicit authentication and permission checks.
Idempotent mutation endpoints where retries are expected.
Webhook events for async workflow integration.
Machine-readable OpenAPI descriptions when endpoint coverage is ready.

Authentication

Public API requests should use scoped credentials that are bound to a workspace and limited by permission.

Example request

curl https://api.qwibik.com/v1/workspaces/ws_123/invoices \
  -H "Authorization: Bearer $QWIBIK_API_KEY"

Workspace scoping

Workspace identifiers should be present in the API route or resolved from the credential. Endpoints that operate on workspace-owned resources must not infer tenant access from resource IDs alone.

Error shape

API errors should be structured for both humans and automation:

error.json

{
  "error": {
    "code": "permission_denied",
    "message": "The API key cannot read invoices for this workspace.",
    "requestId": "req_01J..."
  }
}

Future reference generation

This section is prepared for generated OpenAPI documentation. The current hand-authored overview should remain as the conceptual entry point even after endpoint-level references are added.