SDK

iFirst-party SDKs are not yet shipped

There is no official Honeyframe SDK in v0.0.x. The recommended path is to generate a client from the OpenAPI specification the platform exposes, or to write thin wrappers around the REST endpoints documented in Core API.

First-party SDKs are on the roadmap:

• Python — planned for v1.0.
• JavaScript / TypeScript — planned post-v1.0.

Generating a client from OpenAPI

Each Honeyframe service publishes an OpenAPI 3 document and an interactive Swagger UI:

Service	OpenAPI	Swagger UI
Platform	https://platform.your-domain.com/openapi.json	https://platform.your-domain.com/docs
Hospital	https://hospital.your-domain.com/openapi.json	https://hospital.your-domain.com/docs
Cloud	https://cloud.your-domain.com/openapi.json	https://cloud.your-domain.com/docs

Generate a client with openapi-generator-cli:

# Python
openapi-generator-cli generate \
  -i https://platform.your-domain.com/openapi.json \
  -g python \
  -o ./honeyframe-client-py \
  --additional-properties=packageName=honeyframe_client

# TypeScript (fetch)
openapi-generator-cli generate \
  -i https://platform.your-domain.com/openapi.json \
  -g typescript-fetch \
  -o ./honeyframe-client-ts

Re-run the generator after each platform release; the OpenAPI document is the source of truth and changes per version.

Hand-rolled wrappers

For small integrations a thin wrapper is often cleaner than a generated client. The pattern in Python:

import os
import httpx

class Honeyframe:
    def __init__(self, base_url: str, token: str, org_id: int | None = None):
        self.base = base_url.rstrip("/")
        self.headers = {"Authorization": f"Bearer {token}"}
        if org_id is not None:
            self.headers["X-Org-Id"] = str(org_id)

    @classmethod
    def login(cls, base_url: str, username: str, password: str, **kw) -> "Honeyframe":
        r = httpx.post(f"{base_url}/api/auth/login",
                       json={"username": username, "password": password})
        r.raise_for_status()
        return cls(base_url, r.json()["access_token"], **kw)

    def get(self, path: str, **kw):
        r = httpx.get(f"{self.base}{path}", headers=self.headers, **kw)
        r.raise_for_status()
        return r.json()

    def post(self, path: str, json=None, **kw):
        r = httpx.post(f"{self.base}{path}", headers=self.headers, json=json, **kw)
        r.raise_for_status()
        return r.json()

# Usage
hf = Honeyframe.login(
    base_url=os.environ["HONEYFRAME_URL"],
    username=os.environ["HONEYFRAME_USER"],
    password=os.environ["HONEYFRAME_PASSWORD"],
    org_id=42,
)

datasets = hf.get("/api/datasets")

Token refresh on 401, multi-tenant scoping, and audit-friendly error handling are easy to add as you need them.

What the planned SDK will provide

When the first-party SDKs ship, they'll add value beyond the REST surface:

• Typed models — Pydantic in Python, generated TypeScript types in JS, so IDE autocomplete works against client.datasets.create({...}).
• Auth refresh — automatic re-login on 401 using stored credentials.
• Pagination iterator — for ds in client.datasets.list(): automatically pages through.
• Bulk helpers — client.datasets.upload_csv(path) handles the multipart upload and waits for the import job to complete.
• Retry middleware — exponential backoff on 5xx, configurable per call.
• Test fixtures — a MockHoneyframe class for unit testing your integration without hitting the network.

If you have specific SDK feature requests, file them against the GitHub repository — early input shapes the public API.

Don't depend on the demo helpers

The product repo has internal helpers under paas/backend/services/ that look like SDK functions (auth_service.create_access_token, etc.). Those are server-internal and not designed for client use. Use the REST API.