Papers
Topics
Authors
Recent
Search
2000 character limit reached

Dynamic API Graph for Automated API Synthesis

Updated 11 January 2026
  • Dynamic API Graph is a knowledge graph-based formalism designed to represent and evolve web-accessible APIs through attributed directed graph structures.
  • It encodes API declarations, parameters, and natural language expressions using typed edges and semantic similarity metrics for context-aware mapping.
  • The approach enables automated synthesis of API calls from free-form user utterances, yielding higher precision, recall, and invocation accuracy versus static methods.

A Dynamic API Graph is a knowledge graph-based formalism for representing and evolving the structure, semantics, and invocation logic of web-accessible application programming interfaces (APIs). Designed to facilitate automated synthesis of API calls from natural language expressions, the Dynamic API Graph approach encodes APIs, their declarations, parameters, parameter values, expressions, and semantic similarity information using an attributed directed graph structure. It supports dynamic enrichment via machine learning, user interaction, and word-embedding models. This enables robust mapping from free-form user utterances to concrete, correct API invocations at runtime, outperforming static rules and template-driven methods across precision, recall, invocation accuracy, and coverage metrics (Zamanirad et al., 2017).

1. Formal Definition and Schema

The Dynamic API Graph is formalized as a labeled, attributed directed graph: G=(V,E,A)G = (V,\,E,\,\mathcal{A})

  • VV: set of nodes (entities)
  • EV×VE \subseteq V \times V: set of directed edges (relations)
  • A:VE{attributes}\mathcal{A}: V \cup E \to \{\text{attributes}\}: maps nodes and edges to attribute sets

Nodes VV are partitioned by entity type: V=VAPIVDeclVParamVValueVExprVWEV = V_{\mathrm{API}} \cup V_{\mathrm{Decl}} \cup V_{\mathrm{Param}} \cup V_{\mathrm{Value}} \cup V_{\mathrm{Expr}} \cup V_{\mathrm{WE}}

  • VAPIV_{\mathrm{API}}: API entries (e.g., “Yelp API”)
  • VDeclV_{\mathrm{Decl}}: Declarations (e.g., method+endpoint)
  • VParamV_{\mathrm{Param}}: Parameters (e.g., 'term', 'location')
  • VValueV_{\mathrm{Value}}: Concrete parameter values (e.g., “Italian”)
  • VExprV_{\mathrm{Expr}}: Natural language expressions (e.g., “Find Italian restaurants in Sydney”)
  • VWEV_{\mathrm{WE}}: Word-embedding neighbors for semantic enrichment

Edges EE are typed: E=τTEτE = \bigcup_{\tau \in \mathcal{T}} E_\tau where T={hasDecl,hasParam,hasValue,exprOf,similarTo}\mathcal{T} = \{\text{hasDecl}, \text{hasParam}, \text{hasValue}, \text{exprOf}, \text{similarTo}\}.

Attributes on nodes and edges encode metadata such as API descriptions, HTTP methods, parameter types, value literals, expression texts, and cosine similarity weights for semantic proximity (for similarTo edges).

2. Construction and Evolution

Dynamic construction of the API knowledge graph occurs as APIs are introduced via developer registration or crowdsourcing. The process incrementally adds API nodes, declarations, parameters, and sample utterance expressions, linking them through typed edges (“hasDecl”, “hasParam”, “exprOf”), as illustrated by:

  • Each API AA: Insert node aa with metadata
    • For every declaration dd: Insert node dd, edge (a,d)(a,d)
    • For every parameter pp: Node pp, edge (d,p)(d,p)
    • For each value vv: Node vv, edge (p,v)(p,v)
    • For each sample expression xx: Node xx, edge (x,d)(x,d)

Enrichment leverages word-embedding models (e.g., Word2Vec):

  • For each (p,v)(p,v): Retrieve top-K neighbors {ui}\{u_i\} with cosine similarity above θ\theta
    • Insert word-embedding nodes uiu_i as needed, add “similarTo” edges with similarity weights

Online updates support new parameter values introduced at runtime. If a user provides a new value vv' for parameter pp with a confidence score σ\sigma above a threshold τ\tau, the value is inserted into the graph as a “hasValue” edge annotated by σ\sigma.

3. Storage and Retrieval of API Metadata

All API metadata is encoded via node and edge attributes, supporting input/output schemas, type constraints, usage patterns, and authentication requirements.

  • Declaration nodes (dd) expose A(d).inputSchema\mathcal{A}(d).\mathit{inputSchema}, A(d).outputSchema\mathcal{A}(d).\mathit{outputSchema}
  • Parameter nodes (pp) store fields for requiredness, type, and pattern constraints
  • API nodes (aa) contain authentication attributes (e.g., OAuth2, APIKey)

Graph traversal enables metadata retrieval. For instance, the set of required input parameters for a declaration dd is: Inputs(d)={p(d,p)hasParamA(p).required=true}\mathrm{Inputs}(d) = \{\,p \mid (d,p)\in \mathrm{hasParam} \land \mathcal{A}(p).{\mathrm{required}} = \mathrm{true} \}

4. Mapping Natural Language Utterances to API Calls

Given an utterance S=w1wnS = w_1 \dots w_n, the system:

  • Computes its vector embedding S=i=1nwi\mathbf{S} = \sum_{i=1}^{n} \mathbf{w}_i via word embeddings
  • For each stored sample expression TkT^k, computes Tk\mathbf{T}^k and cosine similarity
  • Selects the declaration decdec^* associated with the best-matching expression

Parameter binding:

  • Extracts entities ee from SS
  • For each parameter pip_i, finds value vi=argmaxvValues(pi)cos(e,v)v^*_i = \arg\max_{v \in \mathrm{Values}(p_i)} \cos(\mathbf{e}, \mathbf{v})
  • Populates parameters with top-matched values, forming a parameter-value matrix

Slot coverage is computed to ensure all required parameters are properly bound: coverage(deck)=1Ni=1N1{pivi}\mathrm{coverage}(dec_k) = \frac{1}{N} \sum_{i=1}^N \mathbf{1}\{p_i \mapsto v_i\} Only if coverage=1\mathrm{coverage}=1, the API call is synthesized and invoked.

Worked Example: For a fragment with Yelp’s GET /search endpoint, given user input “Show me Chinese food places in Sydney”, the system extracts entities (“Chinese”, “Sydney”), maps to parameter values via cosine similarity, and forms the API call:

1
GET https://api.yelp.com/v3/businesses/search?term=Chinese&location=Sydney
Results are retrieved and returned to the user.

5. Comparative Performance Metrics

Empirical comparison of dynamic KG-based synthesis to static intent and template-driven mapping approaches on a 200-utterance evaluation shows:

Method Precision Recall Invocation Accuracy F1-score
Static intents 0.78 0.72 0.65 0.75
Template-based 0.82 0.77 0.71 0.79
Dynamic KG + WE (ours) 0.91 0.88 0.85 0.89

The dynamic KG approach also achieves higher slot-filling coverage (0.93 vs 0.80 for templates). Invocation accuracy (first synthesized call correctly succeeds) is 85% for the dynamic method, which is an approximately 20% absolute improvement over static baselines (Zamanirad et al., 2017).

6. Significance and Broader Context

Modeling APIs dynamically as knowledge graphs supports scalable, extensible, and runtime-adaptable API mediation for natural language interfaces. Rich semantic typing, graph-based retrieval, and word-embedding enrichment allow flexible, context-aware interpretation absent from template or statically-coded intent systems. This approach enables continuous evolution—by integrating new APIs, discovering new parameter values, and learning semantic associations from real user interaction and modern natural language processing methods.

A plausible implication is that such techniques generalize to other application modalities where mappings from unstructured signals (e.g., utterances, descriptions, or queries) to structured action spaces (such as robotic controllers, data transformation pipelines, or dynamic API orchestration in biomedical informatics) are required.

The methodology of representing dynamically-evolving structured resources as attributed, semantically-enriched knowledge graphs and exposing them via API-centric interfaces has also been applied in the biomedical domain, exemplified by Bio-KGvec2go (Ahmad et al., 9 Sep 2025). While the core focus of Bio-KGvec2go is on updating graph embeddings for biomedical ontologies and serving these embeddings via a REST API, both systems employ dynamic data ingestion, graph-based modeling, vector space enrichment, and API-oriented access as foundational principles.

Both lines of work demonstrate that dynamic API graphs and knowledge graph APIs enable automated, accurate, and up-to-date mapping between complex structured resources and downstream user/system intents, with significant ramifications for both conversational software and information integration pipelines.

Definition Search Book Streamline Icon: https://streamlinehq.com
References (2)

Topic to Video (Beta)

Whiteboard

No one has generated a whiteboard explanation for this topic yet.

Follow Topic

Get notified by email when new papers are published related to Dynamic API Graph.