Confirm an owner
Assign a workspace or project owner who can approve models, review usage, and respond when a request is blocked.
Integrations
Point compatible clients and API workflows at New API once. Keep familiar tools while your organization controls model access, usage, and spend.
Before you connect
A reliable integration starts with a clear owner, an approved model, and a key that can be revoked without changing application code.
Assign a workspace or project owner who can approve models, review usage, and respond when a request is blocked.
Check the model catalog and confirm that the capability, context, and provider route fit the intended workflow.
Give the key or team an explicit usage boundary before connecting a shared editor, agent, or service.
Compatible clients
Use New API from the editor, terminal, or compatible API client that fits the workflow.
Editor-based AI workflows
Agent and terminal workflows
Anthropic-compatible workflows
AI-first editor workflows
Coding assistant workflow
OpenAI-compatible configuration
Configure with care
The integration should be easy for a developer to test and easy for an administrator to review.
Store the New API API key in an environment variable or secret manager. Never place it in browser code, a repository, or request logs.
Choose the endpoint that matches the model family, then keep the model identifier and required fields in the request body.
Start with a representative, low-volume request. Confirm the response, usage record, quota behavior, and error handling before rollout.
Agent orchestration
An agent can plan a task, retrieve context, and call an approved model while New API keeps the credentials, model access, and request trail under the same operational controls.
A clear integration path
Select a model and capability your organization has made available.
Configure the client with a New API endpoint and managed API key.
Use request records, quotas, and usage data before expanding access.
Integration FAQ
Use these answers to plan a first connection. The API Reference remains the source of truth for endpoint fields and provider-specific behavior.
Start with one owned workflow, one approved model, and one test key. Connect it in a non-production environment, verify the response and usage record, then expand deliberately.
Use the New API base URL provided for your workspace and select the compatible endpoint for the model family. The API Reference lists the current paths, required headers, and request fields.
Keep it on the server or in the client tool secret store, supplied through an environment variable where possible. Do not expose it in frontend bundles, source control, screenshots, or logs.
They are not interchangeable for every model. New API supports compatible formats where applicable, including Chat Completions, Responses, Anthropic Messages, and Gemini GenerateContent. Check the model and endpoint documentation before switching formats.
Use the model catalog and your workspace permissions together. A model can appear in the catalog but still require an administrator to authorize it for your team or key.
Check the key and header for 401, permissions or model access for 403, the path and model compatibility for 404, and quota or rate limits for 429. Preserve the request ID and review the API Reference or support channel for persistent failures.
Set quotas before launch, use bounded retries with backoff for transient responses, and monitor usage and error rates. Do not retry authentication or permission failures blindly.
Use it whenever you need exact endpoint paths, headers, request schemas, streaming behavior, media fields, or provider-specific constraints. This page explains the integration workflow; the reference defines the contract.