Services for API Providers and Service Providers
I am working with API providers and API service providers to help provide marketing services and agentic-preparation services that help modernize existing API offerings — moving them forward into the AI era.
I am developing standardized packages that support these offerings, but currently I am working with a handful of design partners to define what is possible and needed when it comes to making the transition to support AI. If any of the following maps to something you’re working on, I would love to talk.
Marketing
Tell the API and AI story — through the same channels APIs.io and API Evangelist use to reach API producers, consumers, and the broader API community.
APIs.io & API Evangelist Stories
Crafting and publishing weekly or monthly stories on the APIs.io and API Evangelist blogs. Each story is researched and written in the long-running API Evangelist editorial voice, then surfaced through the network feeds, social channels, and newsletter. Substantive, technical, and indexable — not a press placement.
APIs.io & API Evangelist Feature
Featuring a provider, API, or capability across pages of the APIs.io and API Evangelist websites. Placement runs against the same topic, area, industry, and stage pages that organic visitors and search agents already land on — so the feature lives where the conversation is happening, not on a sidebar nobody reads.
Agentic Preparation
Three deployable services that get an existing API surface ready for the agentic era — without forcing a rewrite of the underlying API, gateway, or portal.
1. Declarative MCP Server on Existing APIs
Deploy a centralized or localized MCP server on top of an existing API, configured entirely in YAML.
The service uses the Naftiko Capabilities framework to engineer the context window for a specific MCP server: pick the path properties you want exposed, declare exactly the data shape the agent should see, and ship. The same engine produces:
- Provider-level MCP servers — the official MCP surface (or suite of surfaces) that a provider publishes for trusted agents.
- Consumer-level MCP servers — downloadable, configurable MCP servers that consumers run themselves to expose only the slice of the provider’s API they actually need.
One declarative substrate, two deployment models — and the agent only ever sees the data the YAML says it should see.
2. Automated Agent Onboarding — As a Naftiko Capability
An agent shows up at your API with a verifiable Web Bot Auth identity, a clear purpose, and a list of scopes it would like. The capability verifies the signature, checks the request against the provider’s declared policy, composes the three-to-five gateway calls needed to provision the agent in your existing API management platform, and returns a scoped credential in a single round trip. No human in the loop. No Jira ticket.
The capability runs on the Naftiko Framework in front of the gateway you already operate. It publishes the four primitives a trusted agent needs to self-onboard:
.well-known/api-catalog— RFC 9727 LinkSet pointing at every spec the provider serves, with anx-onboardingextension declaring the consent document, supported signature schemes, and which scopes auto-issue vs. require approval..well-known/mcp— discovery for any MCP servers the provider operates, and orchestration of any the gateway already manages.- Agent skills at
/skills/— includingonboard-agent.md, the published operating manual the agent reads to know exactly how to register, what to sign, and what to acknowledge. - The
/onboardendpoint — verifies the Web Bot Auth signature (RFC 9421), enforces the provider’s declared trust policy, composes the gateway operations needed to issue a scoped credential, stamps the consent hash and signature onto the audit trail.
Provider policy is declarative — trusted operator domains, auto-issuable scopes vs. approval-required scopes, default rate limits, consent terms, audit destination — all editable without touching the gateway.
Built from gateway operations the major API management platforms already publish (Kong, Apigee, WSO2, Tyk, Gravitee, AWS, Azure, Google). See the accompanying writeup for the per-gateway operation map and tier classification across 75 gateway providers.
3. Next-Generation Integration Page
Replace the static “list of logos” integrations page with a set of declarative, executable integrations between one, two, or more API providers — driven by YAML.
Each integration ships with two execution paths:
- Deterministic workflows — when the integration needs to run the same way every time (Arazzo / typed orchestration).
- Agent skills — when the integration benefits from a non-deterministic, agent-driven approach to retrieving, posting, and updating data across providers.
The provider gets a page that is no longer a marketing artifact but a working integration surface — usable by humans and by agents alike.
Working With Design Partners
These services are being defined in close collaboration with a handful of design partners — API providers and API service providers who are figuring out, in real time, what “AI-ready” actually means for their portfolio.
If you are running an API program and trying to answer questions like “what is our MCP story,” “how do agents onboard against our gateway,” or “what does our integrations page look like once agents are the consumer” — I would like to talk. The standardized packages are coming, but for now each engagement is bespoke and informs how the offering takes its final shape.