Enterprise

Every eligible Kallfi account has ordinary ACR access before Enterprise approval or purchase. This optional Enterprise application is for companies building and operating experiences on platforms they own or control. Enterprise commercial activation is subject to a final agreement; submitting an application does not guarantee approval or immediate activation.

Who Enterprise serves

Enterprise ACR is designed for a company-owned product that needs to create and operate Kallfi Souls through a server-side integration. The contracting company remains responsible for its platform, end-user experience, safety controls, rights, privacy, and data handling.

Use https://acr.kallfi.red/v1 for this site's API. Existing clients may continue using https://api.kallfi.red/v1 as a compatibility host; routes, credentials and machine identifiers are unchanged.

What to prepare

• Company and legal display name, website, and the platform URLs you own or control.
• Your use case, intended users, launch window, expected request volume, and peak concurrency.
• The ACR capabilities you need, including response, image, video, source-asset, or Soul requests.
• Planned source-asset roles, rights and consent basis, likeness requirements, and end-user safety, processing, and retention controls.
• The person responsible for billing and the required ACR, license, and data-processing acknowledgements.

Do not put identity documents or other sensitive evidence in a free-text application. If a requested capability needs private verification, the review flow will name the appropriate secure evidence path.

Review steps

1. Sign in with your Kallfi Account and save an application draft at the matching ACR portal at /enterprise.
2. Submit a frozen application revision with the requested surfaces, capabilities, and acknowledgement versions.
3. Reviewers may request specific additional information, approve defined capabilities, or reject the reviewed revision with a public reason and reapply rule.
4. Approval creates a pending access decision. Activation still depends on the required agreement, identity, safety, environment, provider, and limit checks; approval does not start billing or mint credentials automatically.

Your Enterprise application status and public decision history remain available in the ACR portal after submission. The developer site does not collect credentials, expose reviewer notes, or make a personalized cross-origin session request.

Enterprise plans and organization ACR credits

The following retained Enterprise organization catalog does not gate ordinary account access or fund its account wallet. Enterprise ACR credits are one-time prepaid Gems used for organization content generation and Soul creation. Enterprise plans set the maximum Soul capacity and monthly price; they do not include monthly Gems. ACR credits/Gems are purchased separately, and the exact plan labels below describe the applicable discount without implying a baseline calculation.

Final agreement, taxes, payment method, provider qualification, refunds, expiry, entitlements, and activation evidence remain open commercial gates.

Enterprise usage boundary

Enterprise organization ACR access is licensed to the contracting company and the platforms it owns or controls. It may power and monetize those platforms' experiences, but ACR access or Gem capacity may not be sublicensed, resold, white-labeled, or brokered for another business without a separate written agreement. Every integration remains subject to Kallfi's safety, age, consent, privacy, intellectual-property, prohibited-content, and deletion requirements; commercial access never bypasses a capability or safety decision.

Retained Enterprise organization examples

These examples describe the compatibility contract; an unavailable or unconfigured executor is not enabled by this guide. Confirm your organization’s actual grants and availability before starting paid work.

The examples below retain company-scoped Soul IDs and the organization economy for existing organization integrations, using the current published SDK. They are not the default account wizard or account wallet workflow described above. Enterprise approval does not gate the account commands.

npm install @kallfi/sdk@latest

import { randomUUID } from "node:crypto";
import { Kallfi } from "@kallfi/sdk";

const kallfi = Kallfi.fromEnv();
const accepted = await kallfi.souls.create(
  {
    external_soul_id: "guide-aurora",
    kind: "creature",
    description: "A curious celestial guide with a calm, concise voice.",
    source_asset_ids: [],
  },
  { idempotencyKey: randomUUID() },
);

const operation = await kallfi.operations.wait(accepted.operation.operation_id, {
  timeoutMs: 120_000,
});

console.log({ soulId: accepted.soul.soul_id, operation });

Start a surface-owned operation

The exact surface values are nsfw-disabled and nsfw-enabled. Include surface on every response or generation creation request. Choose it from the operation's intended Kallfi web surface; never derive authorization from a documentation host or a client-supplied label.

import { randomUUID } from "node:crypto";
import { Kallfi } from "@kallfi/sdk";

const kallfi = Kallfi.fromEnv();
const accepted = await kallfi.souls.createResponse(
  "soul_guide_aurora",
  {
    surface: "nsfw-disabled",
    messages: [{ role: "user", content: "Welcome everyone to the stream." }],
    max_output_tokens: 256,
  },
  { idempotencyKey: randomUUID() },
);

const operation = await kallfi.operations.wait(
  accepted.operation.operation_id,
  { timeoutMs: 120_000 },
);

console.log({ surface: accepted.operation.surface, operation });

surface is required for ResponseCreateRequest and GenerationCreateRequest, and Kallfi stores it on the accepted operation. A later GET /v1/operations/{operation_id} returns that immutable surface from the operation ID; it has no surface query or alternate selector. Reusing an idempotency key or resource identity with another surface returns 409 with the stable surface_conflict code.

Raw HTTP

An empty source_asset_ids array creates a Soul from its description alone:

curl --request POST "$KALLFI_API_BASE/souls" \
  --header "Authorization: Bearer $KALLFI_API_KEY" \
  --header "Content-Type: application/json" \
  --header "Idempotency-Key: <stable-unique-key>" \
  --data '{
    "external_soul_id": "guide-aurora",
    "kind": "creature",
    "description": "A curious celestial guide with a calm, concise voice.",
    "source_asset_ids": []
  }'

Do not submit a second create request when a call times out after dispatch. Retry with the same idempotency key and read the original operation until Kallfi reports an authoritative state. In production, signed webhooks avoid continuous polling.

Surface-owned response creation uses this site's canonical ACR origin:

curl --request POST "$KALLFI_API_BASE/souls/soul_guide_aurora/responses" \
  --header "Authorization: Bearer $KALLFI_API_KEY" \
  --header "Content-Type: application/json" \
  --header "Idempotency-Key: <stable-unique-key>" \
  --data '{
    "surface": "nsfw-disabled",
    "messages": [{"role": "user", "content": "Welcome everyone to the stream."}],
    "max_output_tokens": 256
  }'

Generation creation follows the same rule and carries the intended surface in its body:

{
  "surface": "nsfw-enabled",
  "kind": "video",
  "prompt": "Introduce tonight's live show from a neon studio.",
  "quote_id": "quote_live_intro_01",
  "duration_ms": 8000
}

Add source assets

To condition appearance, content style, or live behavior, first create and upload each source asset through POST /v1/soul-source-assets. Wait for asset validation, then include the admitted source-asset IDs in the ordered source_asset_ids array of POST /v1/souls.

Use the ACR reference for complete request schemas, operation states, errors, and webhook contracts.

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.

Plan selection is the first step inside the existing themed Enterprise application. integration.enterprisePlan records catalogId, catalogRevision and planKey. A null catalogId with revision0 is an unpublished-policy request only. Historical omitted fields stay omitted and explicit null stays null. Submit freezes a valid current selection and application revision under the original idempotent command/CAS contract; initial approval creates a NEW nonpersonal organization and Owner membership. Neither step converts Personal. The standalone capacity-preview block is removed; catalog, offer, explicit agreement, checkout, payment and fulfillment remain distinct, and missing commercial terms are never fabricated.

New invitation/resend material is stored atomically through the private Vault-backed delivery carrier and recovered only by service preparation holding the exact live outbox lease. Queue/outbox/audit/command receipts contain locators and digests, never the bearer. Only the intended transactional invitation email carries the private one-use link on the registered /auth/invitation intake; encrypted bounded continuation cleans the URL before login. The intended confirmed Account must explicitly Accept. Canonical replay creates no new carrier or email event; terminal invitation state and bounded expiry purge delete the carrier and its Vault secret. Provider unknown outcomes remain reconciliation-required under the same event idempotency. Source design does not prove SMTP, inbox delivery, provider erasure or active membership.

The normal authenticated self-reader api_platform_get_application(uuid,integer,text) retains its exact applicant_user_id fence, complete DTO and bounded history. Account restriction permits this own read and canonical Personal metadata only; it does not permit another applicant, Team metadata, application mutation, invitation acceptance, proof creation or API execution. The obsolete one-argument application reader remains dropped. New Personal mapping may create standard initial membership/grants, but independent Account restriction still denies execution; reading an existing mapping never restores historical organization/member/grant state.

The portal uses an explicit request-local read-only metadata session for normal Account navigation and self-management reads. It verifies the provider identity, current session, live nonanonymous Account, registered-surface Apple policy and available restriction owner. An active restriction is returned as restricted/false rather than treated as an execution grant. The normal portal login callback explicitly uses the matching consumed-handoff metadata verifier while preserving nonce, PKCE, TTL, target binding, single consumption and cookie transition. The original strict session and consumed-handoff verifier remain strict for key, proof, billing, control-panel and relay consumers. This is reviewed source wiring only: a genuine restricted normal-login/self-read journey and denied Team/key/proof/API paths remain required after installation and deployment.

Native compound33261 and restricted27013 cover the selected canonical invitation/application/metadata command components. They do not establish normal browser continuation, SMTP/inbox delivery or a deployed UI.