OpenAPI Integration

Purpose and Scope

OpenAPI support in this part of the repository is best understood as a LangChain Classic compatibility surface for applications that previously used chain-oriented API helpers. The requested source files do not define a new first-party OpenAPI runtime inside the current main agent package. Instead, they preserve import paths such as OpenAPI endpoint, requester, responder, and prompt symbols while routing those names to community implementations through LangChain Classic’s dynamic importer. That makes the page useful for maintainers migrating older code, debugging imports, or deciding whether to keep a legacy chain or rebuild the behavior as an agent with an HTTP-capable tool.

Sources: libs/langchain/langchain_classic/chains/api/openapi/chain.py, libs/langchain/langchain_classic/chains/api/openapi/requests_chain.py, libs/langchain/langchain_classic/chains/api/openapi/response_chain.py

The broader repository positioning matters for OpenAPI users because modern LangChain documentation emphasizes agents, tools, and interoperable integrations. An OpenAPI specification usually describes external actions that an application can call: request paths, parameters, authentication conventions, and response shapes. In the legacy chain model, language models helped compose or interpret requests and responses through specialized chains. In the current agent-oriented model, the same connectivity goal is usually expressed by giving an agent a constrained tool that performs the HTTP operation, then letting the agent decide when to call that tool as part of a broader task.

Sources: libs/langchain/langchain_classic/chains/api/base.py

Relevant Source Files

• libs/langchain/langchain_classic/chains/api/base.py — Defines the deprecated general APIChain behavior, including API-call summarization, allowed-domain helpers, security warnings, and the recommendation to build new agents with create_agent and an HTTP request tool.
• libs/langchain/langchain_classic/chains/api/openapi/chain.py — Provides the LangChain Classic OpenAPIEndpointChain import surface by dynamically redirecting that deprecated name to langchain_community.chains.openapi.chain.
• libs/langchain/langchain_classic/chains/api/openapi/prompts.py — Preserves REQUEST_TEMPLATE and RESPONSE_TEMPLATE imports for legacy OpenAPI prompt users through dynamic deprecated lookups.
• libs/langchain/langchain_classic/chains/api/openapi/requests_chain.py — Preserves APIRequesterChain, APIRequesterOutputParser, and REQUEST_TEMPLATE imports by delegating to the community OpenAPI requests-chain module.
• libs/langchain/langchain_classic/chains/api/openapi/response_chain.py — Preserves APIResponderChain, APIResponderOutputParser, and RESPONSE_TEMPLATE imports by delegating to the community OpenAPI response-chain module.

System-to-Code Mapping

The OpenAPI compatibility files all follow the same small but important pattern. Each module imports create_importer from the LangChain Classic internal API utilities, declares a DEPRECATED_LOOKUP dictionary from public symbol names to their langchain_community module destinations, builds an _import_attribute function, and exposes a module-level getattr. When a caller imports a preserved name, the module dynamically resolves the attribute and centralizes deprecation handling. This design keeps old import paths functioning while making the migration boundary explicit: the public name remains visible here, but the implementation is owned by the community package destination.

Sources: libs/langchain/langchain_classic/chains/api/openapi/chain.py, libs/langchain/langchain_classic/chains/api/openapi/prompts.py, libs/langchain/langchain_classic/chains/api/openapi/requests_chain.py, libs/langchain/langchain_classic/chains/api/openapi/response_chain.py

The source split also shows the conceptual pipeline used by the legacy OpenAPI helpers. The endpoint module exposes the endpoint-level chain name. The requests-chain module exposes a requester chain and output parser, which implies the step that turns a user goal and API description into an API request representation. The response-chain module exposes a responder chain and output parser, which implies the later step that turns the raw API response into a user-facing answer. The prompts module preserves shared request and response prompt templates, so legacy code that customized prompt text can still resolve those constants through the old namespace.

Sources: libs/langchain/langchain_classic/chains/api/openapi/prompts.py, libs/langchain/langchain_classic/chains/api/openapi/requests_chain.py, libs/langchain/langchain_classic/chains/api/openapi/response_chain.py

Execution Flow for Legacy Chains

A legacy OpenAPI workflow starts with an application importing one of the preserved names from langchain_classic.chains.api.openapi. Python module attribute lookup then reaches the corresponding getattr function if the name is not defined directly in the shim. The importer checks the deprecated lookup table, loads the destination attribute from langchain_community, and returns it to the caller. From the application’s perspective, the old import can continue to work; from the repository’s perspective, the file is a migration adapter that records which names are still part of the compatibility contract.

Sources: libs/langchain/langchain_classic/chains/api/openapi/chain.py, libs/langchain/langchain_classic/chains/api/openapi/requests_chain.py

The general APIChain source provides the most explicit runtime and safety context for this family of functionality. It describes a chain that makes API calls and summarizes the responses to answer a question, and it imports the community TextRequestsWrapper when defining the deprecated class. The class documentation warns that the requests toolkit can issue GET, POST, PATCH, PUT, and DELETE requests. It also says users may be able to make arbitrary requests from the server that hosts the code, including requests to private APIs reachable from that server, so access control and network restrictions are part of the design, not optional deployment details.

Sources: libs/langchain/langchain_classic/chains/api/base.py

API Components

The public names above are compatibility entry points, not an invitation to build new production API access around unconstrained model-generated HTTP calls. The base chain is marked deprecated with an alternative that points developers toward creating an agent and binding a tool that issues the HTTP request. That recommendation aligns with the current agent-framework direction: keep the network operation inside a defined tool, make its inputs explicit, and let the agent use the tool as one capability among others. This is especially important for OpenAPI integrations, because an API specification can expose many endpoints with very different authorization and side-effect profiles.

Sources: libs/langchain/langchain_classic/chains/api/base.py

Security and Migration Guidance

When migrating from these OpenAPI chains, first identify the actual operations your application needs rather than exposing an entire specification unchanged. The base API source includes helper functions that compare a requested URL’s scheme and domain against allowed domains, which highlights one minimum control for HTTP-capable systems. Domain allowlisting is useful, but it does not replace method restrictions, authentication scoping, request validation, rate limits, audit logs, or review of endpoints that mutate state. Treat the OpenAPI document as an implementation aid for building well-scoped tools, not as a blanket permission for an agent to call every path it can describe.

Sources: libs/langchain/langchain_classic/chains/api/base.py

A practical migration path is to keep legacy imports stable while replacing behavior behind them incrementally. Start by cataloging imports of OpenAPIEndpointChain, APIRequesterChain, APIResponderChain, their output parsers, and the request or response templates. Then decide which API actions should become first-class tools in the current agent. For read-only operations, implement narrow request functions with explicit parameters and allowed domains. For write operations, add human review or approval gates where appropriate. Finally, update tests to cover the tool inputs, the HTTP wrapper behavior, and the response summarization separately rather than depending on a single chain to perform every step.

Sources: libs/langchain/langchain_classic/chains/api/openapi/chain.py, libs/langchain/langchain_classic/chains/api/openapi/requests_chain.py, libs/langchain/langchain_classic/chains/api/openapi/response_chain.py

Example Imports and Next Steps

from langchain_classic.chains.api.openapi.chain import OpenAPIEndpointChain
from langchain_classic.chains.api.openapi.requests_chain import (
    APIRequesterChain,
    APIRequesterOutputParser,
    REQUEST_TEMPLATE,
 )
from langchain_classic.chains.api.openapi.response_chain import (
    APIResponderChain,
    APIResponderOutputParser,
    RESPONSE_TEMPLATE,
 )

Use those imports only when maintaining older LangChain Classic code that still depends on the chain API. For new work, design an agent around local tools or integration tools that perform the specific HTTP calls your application allows. Read the tools and agent configuration pages next if you need to model API operations as agent capabilities. Read the sandbox and security page before exposing any network-capable tool to untrusted users. If your goal is broader external connectivity rather than a single OpenAPI specification, compare this page with the provider and tool integration pages so the resulting design follows LangChain’s standard component interfaces.