01
read contractsCatalog, content, and search
Read operations have explicit scopes, pagination, filters, and limits. Response shape does not depend on internal React component state.
FURAZHIR / backend and integration surface
The API is part of the product.
Not a side effect of the interface.
FURAZHIR separates the stable public API v1 from internal Studio server routes. Today, 7 public operations, 54 internal routes, and 39 command contracts are documented, with OpenAPI and a TypeScript SDK for integrations.
- 01public v1 operations
- 7
- 02internal server routes
- 54
- 03command contracts
- 39
- 04machine-readable schema
- OpenAPI 3.1
A small stable surface instead of leaked internal routes
Integrations do not depend on every administrative UI endpoint. The public contract is versioned and limited to operations that can be maintained safely.
02
orders:writeOrder creation
The POST command requires a 32–128 character Idempotency-Key, so a safe retry does not create a duplicate after network uncertainty.
03
observableOne error envelope
Errors, X-Request-Id, and rate-limit headers give integrators predictable diagnosis without parsing HTML or arbitrary messages.
The contract can be read, run, and verified
Documentation is more than a URL list. The schema, SDK, and sandbox present the same request model across different data boundaries.
01
specOpenAPI 3.1
A machine-readable schema describes methods and payloads for the public surface; it supports review and generation of supporting tools.
02
clientTypeScript SDK
The dependency-free client supports timeout, AbortSignal, typed errors, and rejects redirects for credential-bearing requests.
03
try safelyAPI Lab and synthetic sandbox
Developer Hub executes requests against the demo contract and isolates state by workspace without external webhook delivery or live data.
An endpoint is complete only after a reliable effect
HTTP 200 does not guarantee email, webhook, or payment delivery. External effects need an observable background runtime.
01
atomic intentWorker + outbox
The domain transaction and future-effect record commit together; a separate worker performs delivery and manages retries.
02
verify truthWebhooks and re-fetch
Signature and origin are only the first step. After notification, the provider object is fetched again through the API before critical state changes.
03
operationsHealth and operations
Readiness is separated from liveness, the worker has a heartbeat, and audit connects action, result, and request identifier without recording secrets.
Different consumers need different boundaries
Not every internal route should become public. Stability and security are easier when the surface area is deliberately constrained.
| Surface | Consumer | Boundary |
|---|---|---|
| Public /api/v1 | External integrations | Versioned, API key, scopes, limits |
| Demo /api/demo/v1 | Pre-purchase evaluation | Synthetic workspace, no real effects |
| Studio routes | Administrative UI | Server session, CSRF/origin, internal contract |
| Provider webhooks | Payments and integrations | Verification, dedupe, API re-fetch |
| Worker runtime | Background effects | Leases, retries, outbox, heartbeat |
SECRETS AND THE BROWSER
A privileged API key does not belong in a frontend bundle
A server-to-server key lives in a managed backend or integration-platform secret. Direct browser access needs a separate public contract and user model—not publication of an administrative key.
- 01
Authorization: Bearer and X-API-Key are supported for server integrations.
- 02
Scopes constrain key purpose but do not replace rotation and revocation.
- 03
Credential-bearing SDK requests reject redirects so a key cannot cross origins.
Questions about this topic
01Can the API be used without the admin interface?+
Yes. Public API v1 is a separate surface for server-to-server integrations. Studio uses broader internal routes under a server session.
02Can an API key be embedded in a browser app?+
Not a privileged key. Keep it on a server. Direct client access requires separate user authentication and minimal scopes designed for that purpose.
03Can FURAZHIR connect to an existing backend?+
Yes. Existing services can remain systems of record and connect to FURAZHIR through the public API or project-specific adapters.
VERIFY THE CONTRACT
Move from a table operation to a live request
The documentation lists methods, scopes, and purpose, while Developer Hub safely exercises the same contract in a synthetic workspace.