Skip to main content
Version: Dev

Integrations

AISIX integrates with developer tools, application frameworks, AI application platforms, and voice agent platforms through direct client configuration or an operator-managed forward proxy. In both patterns, the client keeps its native request shape while AISIX applies access control, policy, and telemetry.

Most integrations point the client at an AISIX API endpoint and replace the provider API key and model name with an AISIX caller key and model alias. This direct pattern applies to clients that support a custom endpoint for OpenAI-compatible Chat Completions, the OpenAI Responses API, or Anthropic-compatible traffic.

Some tools must keep their official service endpoints and upstream credentials. For those tools, a TLS-terminating egress device can deliver selected traffic to a host-matched AISIX passthrough route. Forward Proxy for IDE AI Traffic demonstrates this pattern with GitHub Copilot.

Both patterns let teams adopt AISIX without rewriting application code or changing the coding tool itself. The client keeps using its familiar SDK, CLI, or framework while gateway policy and observability move into AISIX. Direct integrations also move routing and provider credentials behind AISIX model aliases.

For new OpenAI-family integrations, prefer the client's current recommended API surface when it can still target a custom AISIX base URL. Use the Responses API when the framework provides a first-class Responses client. Use Chat Completions when the client only documents an OpenAI-compatible provider path, or when an existing workflow depends on Chat Completions compatibility.

How Integrations Use AISIX

Direct integrations use the same three AISIX values:

  • The proxy API base URL.
  • A caller API key.
  • A model alias that the caller API key can access.

Many clients describe the third value as a custom model, model ID, model name, or public model name. In AISIX, use the model alias for that field. AISIX authenticates the caller key, resolves the alias to an upstream provider configuration, applies configured policies, and records gateway telemetry.

In the GitHub Copilot forward-proxy pattern, a passthrough route resolves traffic from the trusted egress device to a dedicated caller-key principal. In the primary header_key configuration, the device presents a gateway credential. An anonymous route can instead bind the principal and restrict traffic by source CIDR. The client keeps its official endpoint and upstream credential; the device can also attach a trusted employee identity for attribution.

Integration Types

Client typeUse whenGuides
Client SDKsExisting application code uses an OpenAI- or Anthropic-compatible client.OpenAI SDK, Anthropic SDK
Coding agentsA local editor, AI CLI, remote development environment, or automation job should send requests through AISIX.Coding Agents
Frameworks and librariesAn application framework, agent framework, or AI library should call AISIX from application code.LangChain and LangGraph, LlamaIndex, Haystack, Vercel AI SDK, Pydantic AI, Instructor, OpenAI Agents SDK, CrewAI, Microsoft Agent Framework
AI application platformsA visual application, workflow, or chat platform should send its model requests through AISIX.AI Application Platforms
Voice agent platformsA hosted platform or voice framework should use AISIX for the text LLM step while keeping its own audio and session pipeline.Voice Agent Platforms

Prerequisites

Direct-client guides assume the gateway already has the resources needed for the client path:

  • A caller API key for the application, developer, or automation profile.
  • A model alias that the caller API key can access.
  • A proxy API route compatible with the client, such as OpenAI-compatible Chat Completions, the OpenAI Responses API, or Anthropic Messages.

If AISIX is already deployed for your organization, obtain the gateway URL, model alias, and caller API key from the team that manages it. Otherwise, follow the Open-Source AISIX Gateway Quickstart or AISIX Cloud Quickstart, or contact API7 for Hybrid Cloud access.

The forward-proxy guide has different prerequisites, including a TLS-terminating egress device, permission to configure client proxy and certificate trust, and the current upstream service allowlist.

Provider guides under Models and Providers cover upstream-specific configuration.

Next Steps