AI API Mapper sits between the business APIs you already run and the agents that want to call them — adding contract onboarding, mapping, publication, identity, governance, and auditable execution across REST, SOAP, and OData/Microsoft Graph integrations. Ship it to agents with client SDKs in .NET, TypeScript, Python, and Java.
Downstream APIs were designed for web, mobile, or system-to-system integrations. AI tools need clear names, typed inputs, predictable outputs, and a controlled execution boundary — and someone needs to know who called what, under which tenant, with which credentials.
The platform is a modular monolith with separate executable hosts for administration, runtime execution, background processing, and edge routing — backed by a shared persistence model.
REST admin API plus a web app for human administrators. Onboarding, mapping authoring, toolset and client-app management, identity, governance dashboards, audit review.
The AI-facing execution surface. Presents a per-tenant tool catalog, authorizes callers, resolves credentials, transforms requests and responses, records audits.
Background processing for semantic enrichment, governance audit, and scheduled retention. Message-driven execution, retry handling, and scheduled maintenance are kept outside the request path.
Reverse-proxy entry point in front of all internal hosts. Enforces per-route authentication requirements and lightweight JWT structural validation before proxying. Strips untrusted forwarding and hop-by-hop headers, applies per-identity edge rate limiting by traffic category, and centralizes browser security, request correlation, and ingress observability.
Six functional areas, owned by one platform, configured by humans in the Portal and enforced by the Runtime on every call.
Most of the platform's value lives in four small but specific contracts. They are the ones your engineers will ask about first.
Mappings split what an AI caller sees from what the downstream service receives. ExposedFieldName is the MCP-visible business vocabulary; SourceFieldName is the downstream path the runtime translates to on the way out and back. Structural markers (nested objects, [*] array positions) survive round-trip.
{
"ExposedFieldName": "customerEmail",
"SourceFieldName": "data.party[*].contacts.email"
}Per toolset (overridable per endpoint): Full sends the complete schema with descriptions; Data-Structure-Only keeps the shape but drops descriptions to cut tokens; Lazy returns only a discovery placeholder. When Lazy or DSO is in play, the runtime injects a discover_tool_schema meta-tool that returns the authoritative inputSchema, outputSchema, version and hash.
tools/list → inputSchema: {
"_schema_discovery": "use discover_tool_schema"
}The effective MCP system prompt is composed from the toolset default, the client application prompt (when the assignment opts in), and an optional assignment-specific prompt set to either Append or Override. The same toolset can therefore present different effective prompts to different client applications inside the same tenant.
effective_prompt = toolset.default + (client.prompt if opt_in) + (assignment.custom : append | override)
Request/response logging is opt-in at toolset level with per-endpoint overrides. Captured MCP and downstream HTTP payloads are sanitized: Authorization, token, api_key, secret, password, cookie names are redacted in headers, JSON properties, and query strings. Content past 512KB (configurable) is truncated with a marker.
Authorization: Bearer [redacted]
{ "api_key": "[redacted]", ... }
?secret=[redacted]&limit=20Native client libraries in .NET, TypeScript, Python, and Java expose the same conceptual interface — get the system prompt, get the tools, invoke a tool — with session management, credential injection, and MCP pagination handled internally. Orchestrator adapters convert the tool list into the native format expected by Microsoft.Extensions.AI, Semantic Kernel, Azure AI Foundry Agents, OpenAI, LangChain, LangGraph, and Spring AI.
CodedProjects.AI.ApiMapper.Client
@codedprojects/api-mapper-client
api-mapper-client
com.codedprojects:api-mapper-client
This is not a brochure-first product. The fastest evaluation path is to inspect the architecture, the runtime contract model, and the governance surface in that order.
Start from the platform and runtime specifications to verify how Portal, Runtime, Gateway, and Jobs Worker divide responsibilities, trust boundaries, and operational ownership.
Open architecture docsValidate how exposed fields, source fields, schema discovery, prompt composition, and tool publication work before you invest time in a pilot.
Open Runtime specConfirm how default-deny authorization, sanitized logging, claim checks, and correlation-level trace data behave in a governed production environment.
Open governance docsReview how the platform is deployed inside customer infrastructure, how Runtime nodes are counted, and how the commercial model scales with real production footprints.
Open pricingA selection of platform screens covering onboarding, mapping, governance, and runtime traceability. Useful for technical evaluators who want to inspect how the product behaves in practice.
Shows imported API records, operation counts, schema counts, and the actual onboarding workspace used to start mapping work from OpenAPI and SOAP/WSDL contracts.
Proves that mappings are editable, versioned, and built around exposed versus source field contracts inside the real product UI.
Shows how published mappings become tenant-scoped toolsets with client assignment, MCP URL exposure, and per-toolset behavior.
Confirms that audit exploration, event filtering, and monitoring are first-class product surfaces rather than external tooling.
Shows governed execution stages, timing visibility, and correlation-driven traceability across the full runtime path.
Proves that tool access control is configured as an explicit policy surface instead of being hidden inside custom code.
From OpenAPI or WSDL on disk to a governed, tenant-scoped tool answered by your downstream service — with every hop visible to your operators.
An administrator imports an OpenAPI or SOAP/WSDL document into the Portal.
The platform creates a mapping proposal turning selected operations into business-friendly tool definitions.
Administrators review, edit, approve, version, and publish the mapping.
Published mappings are grouped into a toolset and assigned to one or more client applications.
Configure downstream connectivity, authentication strategies, secret sources, and runtime access policies.
An AI client calls the Runtime to list available tools for a tenant and client application.
Runtime authorizes the caller, resolves credentials, transforms the request, and calls the downstream REST or SOAP API.
Background jobs handle asynchronous work; every call lands as audit + call-trace data, fanned out durably to external compliance targets (REST, syslog, SQL Server, PostgreSQL).
First-class support for Entra ID, Keycloak, and Azure Key Vault. Open standards for trust, transport, and tool exposure. Designed to fit into enterprise identity, messaging, and deployment environments.
Three layers of governance — runtime access, execution, and security — so AI tool exposure stays inside your existing controls.
We'll walk through your environment, your downstream auth shapes, your expected Runtime footprint, and what a realistic first rollout would look like.