---
layout: default
section: Services
title: Services
summary: Marketing and agentic-preparation services for API providers and API service providers — helping modernize existing API offerings for the AI era.
nav: Services
sub: Services
---

<div class="row gx-xl-9">

  <div class="col-12">

    <section>
      <h1 class="fs-3 mb-3">{{ page.title }}</h1>
      <p class="lead text-muted mb-4">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.</p>

      <p class="text-muted mb-5">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.</p>
    </section>

    <section class="mb-5">
      <h2 class="fs-4 mb-3">Marketing</h2>
      <p class="text-muted mb-4">Tell the API and AI story — through the same channels API Evangelist and APIs.io use to reach API producers, consumers, and the broader API community.</p>

      <div class="row">

        <div class="col-md-6 mb-4">
          <div class="card h-100 border-0 shadow-sm">
            <div class="card-body">
              <h3 class="fs-6 mb-2">APIs.io & API Evangelist Stories</h3>
              <p class="text-muted small mb-2">Crafting and publishing weekly or monthly stories on the <a href="https://apievangelist.com/">API Evangelist</a> and <a href="https://apis.io/blog/">APIs.io</a> blogs.</p>
              <p class="text-muted small mb-0">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.</p>
            </div>
          </div>
        </div>

        <div class="col-md-6 mb-4">
          <div class="card h-100 border-0 shadow-sm">
            <div class="card-body">
              <h3 class="fs-6 mb-2">APIs.io & API Evangelist Feature</h3>
              <p class="text-muted small mb-2">Featuring a provider, API, or capability across pages of the <a href="https://apis.io/">APIs.io</a> and <a href="https://apievangelist.com/">API Evangelist</a> websites.</p>
              <p class="text-muted small mb-0">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.</p>
            </div>
          </div>
        </div>

      </div>
    </section>

    <section class="mb-5">
      <h2 class="fs-4 mb-3">Agentic Preparation</h2>
      <p class="text-muted mb-4">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.</p>

      <div class="row">

        <div class="col-md-12 mb-4">
          <div class="card h-100 border-0 shadow-sm">
            <div class="card-body">
              <h3 class="fs-6 mb-2">1. Declarative MCP Server on Existing APIs</h3>
              <p class="text-muted small mb-2">Deploy a centralized or localized MCP server on top of an existing API, configured entirely in YAML.</p>
              <p class="text-muted small mb-2">The service uses the <a href="https://naftiko.io/">Naftiko Capabilities</a> 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:</p>
              <ul class="text-muted small mb-2">
                <li><strong>Provider-level MCP servers</strong> — the official MCP surface (or suite of surfaces) that a provider publishes for trusted agents.</li>
                <li><strong>Consumer-level MCP servers</strong> — downloadable, configurable MCP servers that consumers run themselves to expose only the slice of the provider's API they actually need.</li>
              </ul>
              <p class="text-muted small mb-0">One declarative substrate, two deployment models — and the agent only ever sees the data the YAML says it should see.</p>
            </div>
          </div>
        </div>

        <div class="col-md-12 mb-4">
          <div class="card h-100 border-0 shadow-sm">
            <div class="card-body">
              <h3 class="fs-6 mb-2">2. Automated Agent Onboarding — As a <a href="https://naftiko.io">Naftiko Capability</a></h3>
              <p class="text-muted small mb-2">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.</p>
              <p class="text-muted small mb-2">The capability runs on the <a href="https://naftiko.io">Naftiko Framework</a> in front of the gateway you already operate. It publishes the four primitives a trusted agent needs to self-onboard:</p>
              <ul class="text-muted small mb-2">
                <li><code>.well-known/api-catalog</code> — RFC 9727 LinkSet pointing at every spec the provider serves, with an <code>x-onboarding</code> extension declaring the consent document, supported signature schemes, and which scopes auto-issue vs. require approval.</li>
                <li><code>.well-known/mcp</code> — discovery for any MCP servers the provider operates, and orchestration of any the gateway already manages.</li>
                <li><strong>Agent skills at <code>/skills/</code></strong> — including <code>onboard-agent.md</code>, the published operating manual the agent reads to know exactly how to register, what to sign, and what to acknowledge.</li>
                <li><strong>The <code>/onboard</code> endpoint</strong> — 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.</li>
              </ul>
              <p class="text-muted small mb-2">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.</p>
              <p class="text-muted small mb-0">Built from gateway operations the major API management platforms already publish (Kong, Apigee, WSO2, Tyk, Gravitee, AWS, Azure, Google). See the <a href="/2026/05/27/automated-agent-onboarding-is-a-naftiko-capability-not-a-gateway-feature/">accompanying writeup</a> for the per-gateway operation map and tier classification across 75 gateway providers.</p>
            </div>
          </div>
        </div>

        <div class="col-md-12 mb-4">
          <div class="card h-100 border-0 shadow-sm">
            <div class="card-body">
              <h3 class="fs-6 mb-2">3. Next-Generation Integration Page</h3>
              <p class="text-muted small mb-2">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.</p>
              <p class="text-muted small mb-2">Each integration ships with two execution paths:</p>
              <ul class="text-muted small mb-2">
                <li><strong>Deterministic workflows</strong> — when the integration needs to run the same way every time (Arazzo / typed orchestration).</li>
                <li><strong>Agent skills</strong> — when the integration benefits from a non-deterministic, agent-driven approach to retrieving, posting, and updating data across providers.</li>
              </ul>
              <p class="text-muted small mb-0">The provider gets a page that is no longer a marketing artifact but a working integration surface — usable by humans and by agents alike.</p>
            </div>
          </div>
        </div>

      </div>
    </section>

    <section class="mb-5">
      <h2 class="fs-4 mb-3">Working With Design Partners</h2>
      <p class="text-muted mb-3">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.</p>
      <p class="text-muted mb-3">If you are running an API program and trying to answer questions like <em>"what is our MCP story,"</em> <em>"how do agents onboard against our gateway,"</em> or <em>"what does our integrations page look like once agents are the consumer"</em> — 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.</p>
      <p class="mb-0"><a href="mailto:info@apievangelist.com" class="btn btn-outline-secondary btn-sm">Get in touch — info@apievangelist.com</a></p>
    </section>

  </div>

</div>