API-Driven Code Generation Approach

• API-driven code generation is a method that treats APIs and their documentation as central units for retrieving, planning, and verifying code.
• It integrates multi-stage pipelines such as documentation retrieval, API dependency analysis, and runtime execution to handle unknown libraries and evolving interfaces.
• The approach boosts code synthesis reliability by combining contract-driven generation, automated testing, and validation loops to meet interface constraints.

Searching arXiv for the papers on arXiv and closely related work to ground the article in current literature. An API-driven code generation approach is a family of methods in which APIs are treated as the central organizing unit of generation, retrieval, planning, or verification rather than as incidental tokens emitted by a general code model. In this literature, the driving signal may be API documentation and signatures for unknown libraries, explicit tool use for API search, dependency graphs over API methods, OpenAPI contracts, or executable API-specific harnesses used to validate inferred behavior. The result is not a single technique but a spectrum of contract- and API-centric workflows spanning code synthesis, test generation, interface recovery, service generation, and dynamic verification (Washio et al., 2022, Zhang et al., 2023, Liu et al., 29 Nov 2025, Chauhan et al., 22 Oct 2025, Hu et al., 5 Oct 2025).

1. Conceptual scope and defining characteristics

The common premise is that modern software development is dominated by libraries, frameworks, SDKs, and web services, so the critical generation problem is often not unrestricted token prediction but correct selection and composition of APIs under interface, dataflow, and usage constraints. In this sense, “API-driven” denotes a shift from generic language modeling toward methods that explicitly model API names, signatures, dependencies, parameter schemas, contracts, or runtime behavior.

Across the literature, several recurring formulations appear. One formulation treats code generation as prediction of API calls or API sequences under semantic constraints. Another treats API documentation as an external memory from which unknown primitives can be retrieved and copied at inference time. A third treats API specifications such as OpenAPI as executable contracts that can drive test generation, SDK recovery, or service implementation. A fourth uses generated API-specific code not as the final product but as a verification instrument, as in Android permission analysis (Hu et al., 5 Oct 2025).

This suggests a useful distinction between API-aware and API-driven generation. API-aware systems may merely benefit from API mentions in training data. API-driven systems instead reorganize the entire pipeline around APIs: they retrieve API signatures, embed API dependency graphs, generate API-specific harnesses, or constrain output around documented or inferred contracts. Early work on API recommendation and next-call prediction already exhibited this orientation by modeling dependence paths and typed API relations rather than plain token sequences (Xiao et al., 2021, Lyu et al., 2021).

2. Documentation-grounded generation for unknown and evolving libraries

A major branch of API-driven generation starts from the observation that code models cannot be assumed to memorize the APIs they need at test time. “Code Generation for Unknown Libraries via Reading API Documentations” implements a three-stage pipeline—API Retriever, API Reader, and Code Generator—in which relevant signature-description pairs are retrieved from documentation and the decoder can copy API symbols from retrieved signatures. On the library split, CopyNet reaches BLEU 12.15, while the documentation-reading model reaches 15.98 in the Oracle setting and 13.58 in the Partially-Real-World setting; for OOV primitive recall, CopyNet scores 0.0, versus 21.6 in the Oracle setting and 4.8 with retrieved signatures (Washio et al., 2022). The important point is architectural: support for unseen libraries becomes a retrieval problem over documentation rather than a vocabulary memorization problem.

Tool-mediated retrieval can be integrated even more tightly into decoding. ToolCoder fine-tunes code models to emit serialized tool calls of the form APISearch(query) -> answer, interrupts decoding to execute the search, reinserts the answer, and then resumes generation. This yields average improvements of at least 6.21% on pass@1 and 9.64% on pass@10 across five public and private library benchmarks, while also showing that a relatively small ToolCoder model can be comparable to GPT-3.5 on some settings (Zhang et al., 2023). The central design lesson is that API lookup need not be a preprocessing step; it can be a learned action inside generation.

The same retrieval-centered logic appears in workflow DSL generation. “Plan with Code” studies NL-to-DSL generation for workflow automation over 700 publicly available APIs and shows that a fine-tuned model performs best on code similarity overall, but optimized RAG can match the quality for in-domain API names and outperform the fine-tuned model on similarity by 7 points for out-of-domain or unseen API names (Bassamzadeh et al., 2024). Here, few-shot examples teach DSL syntax, while attached API metadata grounds exact callable names and parameter keys.

At a larger systems level, Doc2Agent turns unstructured REST documentation into Python tools that can be loaded into agents. Its pipeline parses HTML or Markdown documentation into a structured intermediate form, generates wrappers, validates them by execution, and iteratively refines broken tools with a code agent. On WebArena, it reports a 55.1% relative performance improvement and 90% lower per-task cost compared to direct API calling, and the refinement loop improves tool pass rates by 47.6% (Ni et al., 24 Jun 2025). In this formulation, API-driven code generation becomes a compilation process from documentation to executable tool interfaces.

3. Execution-grounded generation, exploration, and verification

A second branch emphasizes that API knowledge retrieved from documentation or inferred from code still remains uncertain until it is exercised. These methods therefore generate code that is meant to run, observe errors, and use execution as a correctness signal.

Bamboo is a particularly clear example because its “API-driven code generation approach” is explicitly not the whole method but the verification stage of a larger Android API-permission discovery pipeline. After API extraction and dual-role LLM analysis, Bamboo generates self-contained test cases for permission-requiring Android APIs, reuses existing test cases from BigCodeBench and Complexcodeeval when possible, validates them for self-containment and SDK compatibility, and executes them inside demo apps on an emulator. Mappings are confirmed when invoking an API without the required permission triggers a security exception whose message reveals the permission. The full pipeline identifies 2,234 mappings on Android 6, 3,552 on Android 7, 4,576 on Android 10, and 3,264 on Android 15 (Hu et al., 5 Oct 2025). Here, code generation functions as a runtime validation instrument rather than as an end-user programming assistant.

ExploraCoder extends the execution-grounded idea to multi-API synthesis for unseen libraries. It decomposes a programming problem into API-invocation subtasks, retrieves APIs per subtask, and runs a chain-of-API-exploration in which the model generates intermediate code candidates, executes them, observes outputs and errors, and carries selected experience forward. On Torchdata-Manual, pass@10 rises from 0.95% to 11.61% for GPT-3.5-turbo-0125 and from 0% to 23.27% for GPT-4-0613; with the self-debug extension ExploraCoder*, pass@10 reaches 16.75% and 36.22% respectively (Wang et al., 2024). The method is API-driven because the planning granularity, retrieval context, and execution traces are all organized around concrete API-invocation subtasks.

Execution-grounded API generation can also be used to discover behavior rather than solve a programming task. “Exploring API Behaviours Through Generated Examples” uses meta-properties such as response equality, response inequality, and state mutation to generate minimal black-box examples of API behavior without source code or formal specifications. Symbolic references are central: for MP-S-3, median effort drops from 1000.0 under random parameter generation to 62.0 or 55.5 when references are used (Karlsson et al., 2023). In this setting, the generated artifact is a minimal executable trace whose value lies in revealing behavior, not merely demonstrating syntax.

4. Structural API knowledge as a generation prior

Another line of work treats APIs not primarily as documentation objects but as structured graphs, dependence paths, or compositional operators. The goal is to inject global API semantics into generation, recommendation, or synthesis.

ADG-Seq2Seq models global API dependencies through an API Dependency Graph whose nodes are API methods and whose directed tagged edges denote type-matched data dependencies between outputs and inputs. The decoder substitutes API token embeddings with graph-informed node embeddings learned through neighborhood aggregation and topological ordering. On Java datasets, the method outperforms prior models across major metrics; it also raises the Percentage of valid code to 55.1% on MTG and 53.0% on E-JDT, versus 20.8% and 19.3% for attention-based Seq2Seq (Lyu et al., 2021). The underlying claim is that code generation quality depends on respecting API invocation constraints and invocation order, not just local token plausibility.

Multi-HyLSTM reaches a similar conclusion from a recommendation perspective. It extracts dependence paths from API dependence graphs over Java cryptographic code and uses a hybrid-loss LSTM plus multi-path aggregation to predict the next API method call. The resulting top-1 recommendation accuracy reaches 91.41%, compared with 77.44% for SLANG, and on 245 manual test cases it reaches 88.98%, compared with Codota’s 64.90% (Xiao et al., 2021). In this case, API-driven generation is a next-call completion problem guided by semantically meaningful program-analysis paths.

“Predictive Synthesis of API-Centric Code” addresses synthesis from input-output examples by predicting ordered API sequences before enumerating arguments. Its Full-Seq variant reduces mean and max synthesis time from (10.01, 96.53) to (1.04, 9.58), whereas a DeepCoder-style multi-label baseline only reduces them to (7.44, 77.00) (Nam et al., 2022). The distinctive claim is that the model can learn to compose API functions via hidden-state representations of intermediate states even when those intermediate values are not explicitly observed.

In low-resource frameworks, the same structural perspective can be used to synthesize supervision rather than directly generate code. APIKG4SYN builds an API knowledge graph from HarmonyOS documentation, uses uncertainty-estimation-driven Monte Carlo Tree Search to assemble informative multi-API compositions, synthesizes 8,000 API-oriented question-code pairs, and fine-tunes small models on the resulting data. Qwen2.5-Coder-7B reaches 25.00% pass@1 with APIKG4SYN, compared with 17.59% for GPT-4o, and removing multi-API samples drops the score to 10.19% (Liu et al., 29 Nov 2025). Here, the API graph is the organizing structure for data generation and framework adaptation.

5. Interface synthesis, specification recovery, and contract-centered generation

API-driven generation is not limited to producing client code that uses existing APIs. It also includes synthesizing reusable interfaces from fragments, recovering formal contracts from implementations, and generating systems from those contracts.

Code2API frames “APIzation” as the transformation of partial Stack Overflow snippets into reusable callable units. Its prompt design decomposes the task into eight steps: recover imports, define a wrapper class, create a public static method, infer a method name, infer parameters, infer return statements, infer throws declarations, and output the complete code. In the ISSTA tool version, Code2API achieves 66.0% accuracy on input parameters, 65.0% on return statements, and 43.5% on equivalent method implementations, and its generated method names score an average of 3.65 in descriptiveness versus 2.23 for APIzator and 3.39 for human-written APIs (Mai et al., 19 Apr 2025). This is API-driven generation in the sense of synthesizing a reusable API boundary around informal code.

A parallel line reverses the direction: instead of generating code from API specifications, it generates specifications from code. AutoOAS statically analyzes Spring Boot source code to recover endpoint paths, HTTP methods, parameters, responses, and reusable schemas, including inheritance. On seven real-world projects, it achieves overall precision/recall of 1.00/1.00 for methods, 0.73/0.69 for parameters, and 0.99/0.97 for responses (Lercher et al., 2024). OOPS extends this idea to a technology-agnostic LLM-based static analysis workflow across 12 APIs, 5 programming languages, and 8 development frameworks, reaching average F1-scores of 98.8% for endpoint method inference, 97.2% for request parameter inference, 97.0% for response inference, and 92.3% for parameter constraint inference (Chen et al., 19 Jan 2026). In both cases, the generated OpenAPI artifact becomes a machine-readable contract that can drive downstream code generation, testing, or client synthesis.

OpenAPI can also serve as the direct source artifact for code generation. “From Specification to Service” uses a multi-agent system to automate API-first development for RESTful microservices: generate an OpenAPI specification, generate server code from it, run the service locally with Docker, analyze logs, and invoke a code-fixer agent when necessary. On the filtered PRAB benchmark, 5 of 7 generated services ran successfully on the first attempt and 7 of 7 after repair, while all seven implemented all endpoints and HTTP methods in the corresponding specification (Chauhan et al., 22 Oct 2025). APITestGenie applies the same contract-centered principle to test generation rather than service implementation: given business requirements plus OpenAPI specifications, it generates executable Jest + TypeScript API test scripts, reaching 57.3% valid scripts in a single attempt and about 80% valid@3 across 10 real-world APIs (Pereira et al., 2024).

6. Reliability, evaluation, and recurring limitations

Because API-driven generation aims at executable interaction with real interfaces, evaluation in this area tends to privilege validity, executability, and contract adherence over token overlap alone. This has led to a strong emphasis on repair loops, auxiliary evaluators, and human-in-the-loop workflows.

One approach is post-training alignment around API-usage quality. The RLAIF framework for lightweight models uses GPT-3.5 to score generated Python code along eight binary dimensions, including whether the code imports necessary modules, uses the correct APIs, and is functional. The resulting 780M model improves executability from 23.4% to 27.9%, and surpasses the 7B Gorilla baseline’s 26.9% by 1.0 point (Dutta et al., 2024). Another approach is explicit knowledge-driven repair. KPC builds a knowledge base of 19,057 exceptions with corresponding conditions for 11,477 Java SDK/JDK APIs, extracts the fully qualified API names used in generated code, checks whether documented exceptions are handled, and rewrites the code with fine-grained prompts of the form “Please check [Condition] for [API], otherwise throw [Exception].” On a sample of 384 tasks, manual review rises from 56 valid outputs for baseline ChatGPT to 380 for KPC, and dynamic validation finds 18 fewer runtime bugs (Ren et al., 2023).

A recurrent misconception is that API-driven generation eliminates uncertainty because APIs are formally documented. The literature repeatedly shows that this is false. Retrieval quality is often the bottleneck: in documentation-grounded unknown-library generation, OOV primitive recall falls from 21.6 in the Oracle setting to 4.8 when signatures are retrieved automatically (Washio et al., 2022). Runtime pipelines remain expensive and partially manual: Bamboo reports an average cost of about 50 USD and 25 hours to analyze one SDK version, and explicitly notes occasional manual intervention because of the inherent variability and instability of LLM outputs (Hu et al., 5 Oct 2025). Stateful APIs remain difficult to validate automatically in Doc2Agent, which notes that validating stateful APIs often requires multiple coordinated calls and additional endpoints to observe state (Ni et al., 24 Jun 2025).

Specification-driven workflows do not remove the need for review either. OOPS still has lower performance on parameter constraints than on endpoints and responses, and its error analysis highlights failure cases involving dynamic route registration, nested request bodies, and unconventional serialization (Chen et al., 19 Jan 2026). APITestGenie reaches only partial automation and explicitly recommends human intervention to validate or refine generated scripts before integration into CI/CD pipelines (Pereira et al., 2024). Across the field, the stable pattern is therefore not “fully automatic API coding,” but generation augmented by retrieval, structural priors, execution, verification, and selective human correction.

A plausible implication is that API-driven code generation is best understood as an interface-centered systems paradigm rather than a single decoding trick. Its strongest forms combine at least three elements: an external API knowledge source such as documentation or specifications, a generation mechanism that treats APIs as first-class objects, and a validation loop that checks behavior against executable evidence or contract structure. Within those bounds, the approach has already shown strong results on unknown libraries, multi-API planning, permission verification, low-resource frameworks, contract recovery, service generation, and automated API testing (Wang et al., 2024, Liu et al., 29 Nov 2025, Lercher et al., 2024, Chauhan et al., 22 Oct 2025).