Integrate a production application
Keep authorization, operation identity, budgets, and observability aligned across the whole request path.
Your backend should be the boundary between an end user or agent and Internalize. It holds the project key, chooses the authorized subject, records durable intents, and decides when a result can be used by the application.
Establish the request path
Authenticate the caller in your own application. Resolve their project and subject mapping from trusted state. Validate the proposed question or knowledge update, then create an operation record before calling Internalize.
Return an application operation ID if the work is still pending. A durable background task can read the Internalize job and update your record. This avoids tying a potentially long training job to one short-lived browser connection or serverless request.
Separate capabilities
Use separate credentials for inference serving and learning or release automation when practical. An inference-only service should not be able to train arbitrary knowledge or manually activate a version. Submitting keys can poll their own jobs. Add read only for project-wide inspection.
Keep the key out of the model prompt and browser bundle. Do not let a tool argument select an unrestricted subject in a shared project. The model proposes an action; the server verifies that the action belongs to the authenticated caller's workspace.
Bound work and spending
Choose an output ceiling appropriate for your answer format. Large ceilings increase the admission reservation even when actual output is usually small. Keep the project spending limit aligned with the application's intended budget, and observe available credit separately from the monthly cap.
Queue dependent internalizations per subject. Apply application-level deduplication to repeated memory proposals before creating new paid intents. A retry of the same intent keeps its key; a deliberate new update receives a new identity.
Preserve operational evidence
Record the job ID, HTTP request ID when available, status, error code, adapter version, timings, and final integer charge. Link a learning job to your source revision without putting source content into ordinary logs.
Keep metrics for admission failures, time to terminal outcome, rejected candidates, activation conflicts, unsettled reservations, and reconciliation cases. The public API currently offers polling rather than customer webhooks, so your monitoring task should read known jobs and back off appropriately.
Recover safely
On a lost admission response, recover with the same body and key. On a failed poll, read the same job later. On reconciliation, preserve the reservation and request investigation. On an expired adapter, fail explicitly in your application rather than silently switching to an untrained subject and claiming the same knowledge is available.
A client timeout or user dismissal is not cancellation. Make that clear in your own UI and avoid a retry button that starts duplicate paid work.
Verify the enabled deployment
The current hosted environment is a console preview with billing and execution gated. Before live use, confirm that your project has a durable account, live payment setup, an actual paid balance, and enabled model execution. Then run the small end-to-end quickstart and inspect real jobs and charges.
Read Availability, Polling, and Deploying updates. These docs describe the supported public interface; provider worker credentials and private service routes stay behind the platform boundary.