Kallfi ACR

Use Kallfi ACR to create Souls, generate content and manage creator workflows from your backend.

Account access

Basic ACR access is available to every Kallfi Account without an Enterprise application. Reveal your key in Account Settings or your ACR account. Keep it in your server secret manager and use https://acr.kallfi.red/v1 for requests on this surface.

Your Account's eligibility, content safety, quota, Gems and payment requirements still apply to each action. Rotating a key revokes its predecessor.

What you can build

Use content you own or are authorized to use. Uploading Posts requires the Account's current public-display acknowledgment in Kallfi's upload flow; an API key does not record that consent.

Build reliable integrations

• Keep ACR keys on your server and use the matching surface's host.
• Retain one UUID idempotency key for each intended mutation and reuse it for retries.
• Follow accepted asynchronous work to its completed result before treating it as finished.
• Use the documented operation schema for required pricing, permissions and input fields.
• Handle revision conflicts and bounded, cursor-based lists as described in the reference.

Enterprise

Enterprise adds organization applications, review and commercial terms. Ordinary Account access remains available independently; existing organization integrations retain their documented grants and billing rules.

Choose your integration

Start with the SDK Quickstart, browse the ACR reference, or connect an AI client through MCP setup.

Following Account/workspace overhaul — source and proof boundaries

This section describes the reviewed following source candidate. It does not claim that its workspace schema, portal UI or runtime is installed on the currently serving deployment. Published packages and the separately verified hosted MCP Personal reads remain valid; explicit hosted Team requests currently fail closed until the matching workspace implementation is adopted.

New sign-in and unscoped browser entries default to Personal, including unscoped Enterprise. Explicit /org/<id> navigation, or an explicit Enterprise organization query, retains the chosen workspace across internal tabs; an application, first membership, sole membership or saved hint never silently selects it. The compact membership-paged workspace menu is navigation, not an authorization grant.

One Account key per COM/RED surface identifies the Account across its currently authorized workspaces. X-Kallfi-Workspace-ID is an optional, untrusted UUID selector; omitted selection means Personal for Account keys. Organization runtime commands derive surface from the registered host and recheck the current Account, credential, membership role/ceiling, grant and row ownership. Workspace changes never mint, reveal, rotate or move a key. Legacy Enterprise credentials remain pinned to their original organization and grants; this selector cannot widen them.

In the original 38-operation baseline, the 31 canonical Account product commands retain the real Account actor, ownership and Account wallet. They support Personal only; an otherwise authorized nonpersonal selection returns workspace_operation_not_supported/409 before the Account action executes. The 7 organization operations use the selected workspace and its existing capability, rights, safety and organization economy; selecting Personal or a team does not invent funding, paid benefits or provider readiness. Host/key mismatch, revoked credentials and lost membership fail closed. Account-origin RED policy remains canonical: Apple-origin is unavailable, and missing or ambiguous provider provenance fails closed.

Personal workspace metadata is owned by the eligible Account’s exact Account→Personal mapping. Both workspace bootstrap and the full organization getter retain access to that metadata even when its historical organization/member status is suspended or revoked or its surface ceiling is empty. They return the actual persisted status, role, revisions, ceilings, grants and owner projections; they never reactivate rows or replace a full organization record with a compact chooser summary. The full getter adds a server-derived workspaceKind discriminator; existing function arguments and legacy active-member responses remain compatible. Team metadata retains its current membership/surface checks.

Personal metadata access is not execution authority. Key lifecycle and selected-workspace operation admission separately enforce Account eligibility, explicit credential revocation and current workspace execution grants/membership. Portal route loading must use the full getter consistently with bootstrap to avoid a default-Personal redirect loop, and must carry the Personal kind into management controls so Personal is not treated as a team.

Workspace protocol discovery

GET /v1/capabilities is an unauthenticated, side-effect-free protocol discovery endpoint on the same canonical ACR origin as the intended request. It is separate from the 38 business-operation catalog and creates no MCP business tool or operation ID. Send no credential, workspace selector or request body. A supporting server returns HTTP200 with Cache-Control: no-store and this exact bounded JSON:

{
  "protocolVersion": 1,
  "workspaceSelection": "account-principal-v1",
  "selectorHeader": "X-Kallfi-Workspace-ID",
  "omittedWorkspace": "personal",
  "explicitWorkspaceScopes": [
    "organization-runtime"
  ],
  "accountOperationWorkspace": "personal-only"
}

Before every explicitly scoped workspace business read or mutation, the shared SDK requires this exact protocol from the same origin. It rejects redirects, missing routes, HTML, non200, oversized/malformed JSON or a mismatched protocol before sending the business request. A missing or unavailable protocol never falls back to an unscoped request. Omitted-workspace legacy requests retain their existing transport contract. No cross-origin capability cache or environment feature flag is authority.

The route is co-released with the actual workspace-aware transport. Its service-only, bounded catalog-read readiness owner checks the ten exact resolver/runtime/immutable-receipt function identities and receipt table before advertising support. It invokes no Account/business mutation, creates no key, and discloses no identity, credential, role or membership data. Unavailable implementation returns503 workspace_protocol_unavailable. Discovery does not authorize a selected workspace: each subsequent request re-admits the current Account credential, Account status, selected membership/revisions, surface, organization and capability grant.

Document discovery separately from generated business OpenAPI/MCP operations; do not alter the retained 38-operation snapshot/hash merely to add protocol discovery. Hosted route/schema availability is independent deployment evidence, not implied by source review.

Accepted native component evidence

Each retained run completed naturally with exact owned database/container removal and both resource leases returned. Earlier failures remain historical evidence. Source integration/compiler/RSC, exact hosted migration history and owner readback, matching runtime deployment, normal authenticated/restricted portal journeys, end-to-end invitation acceptance and SMTP/inbox delivery remain separate unfinished release evidence. Native command acceptance does not establish paid provider fulfillment. No blanket native-pending statement supersedes these scoped successes.

Principal-kind boundary and focused native proof

Credential kind is determined by the canonical Account-key credential association, not by whether its organization is the Account’s Personal workspace. A genuinely issued legacy organization credential in Personal retains legacy authority and normal scope revocation; it is not exempted as an Account key. Current Account credentials preserve their independent Account identity while each workspace operation still checks its current grants and accepted immutable tuple.

The independently reviewed native principal-kind run33969 reproduced the original surface/missing-tuple errors through a genuine public issuer and original public acceptance. Corrected public acceptance and actual leased-worker context permit legacy Personal work while true Account work missing its immutable tuple remains denied. A canonical public Admin grant revocation revokes the legacy credential/revision and conserves the complete Account credential row plus other-workspace admission. All focused changes rolled back with natural zero and exact owned cleanup. This does not prove hosted adoption, rotation/deletion, provider output or complete rollout.

Application approval review policy

For the following approval-owner correction, every approved or pending grant item selects one to six unique activation requirement codes and may carry bounded initialLimits. Decision items must cover exactly the submitted surface/capability pairs. These are review policy inputs: approval leaves the organization inactive, grants pending activation, and every selected requirement pending. It does not satisfy evidence, activate access, create free commercial terms, or authorize a purchase. Canonical server evidence owners retain authority over readiness.