How to Monetize Your AI Agent with IntentLink: A Quick-Start Guide

TL;DR

If you're building an AI agent and want to add native shopping and travel monetization without breaking the conversational experience, IntentLink gives you two integration paths — a self-describing MCP endpoint, or a direct REST API. Either way, every result your agent gets back already includes a ready-to-use, trackable purchase link — there's no separate "resolve the link" step. This guide walks through both paths using IntentLink's actual API.

Two Ways to Integrate

Both paths call the same underlying shopping and travel search services, so there's no difference in result quality between them.

Our recommendation: start with MCP. Its fields are a simplified, agent-friendly subset, so most agents can integrate in minutes. Reach for REST only once you have a specific need for finer-grained control than MCP's simplified fields provide.

A quick note: IntentLink's API is in active beta, so some details here may evolve — check the full docs for the latest, and reach out if you hit any snags.

Before You Start

You'll need a registered, activated agent_id — get one from the developers page. It does double duty: it's your admission key (calls from an unregistered or inactive agent_id are rejected) and your attribution key (any resulting click or purchase is credited back to you).

Option A: Integrating via MCP

MCP is designed to be self-describing — once your agent is connected, it can call tools/list and get the available tools, their parameters, and usage guidance without you having to hand-write integration logic for each one. Today there are two tools available: search_products for shopping, and search_travel for travel (hotels, flights, bundles, airport transfer, car rental).

Connecting from Claude (Messages API):

{
  "model": "claude-opus-4-8",
  "max_tokens": 1024,
  "mcp_servers": [
    { "type": "url", "name": "intentlink-shopping", "url": "<YOUR_MCP_ENDPOINT>" }
  ],
  "messages": [
    { "role": "user", "content": "Find a good running shoe for my wife under $120 and give me the buy link. My agent_id is agt_your_agent_id." }
  ]
}

Using Claude Desktop or connectors instead of the API directly? Just add the same endpoint URL as a remote MCP server (Streamable HTTP) — no code required.

Connecting from OpenAI's GPT models (Responses API):

{
  "model": "gpt-5",
  "input": "Find 3 cheap wireless earbuds under $50 and give the buy link for the cheapest. agent_id agt_your_agent_id.",
  "tools": [
    { "type": "mcp", "server_label": "intentlink_shopping", "server_url": "<YOUR_MCP_ENDPOINT>", "require_approval": "never" }
  ]
}

Connecting from a generic MCP client (for testing connectivity):

from mcp.client.streamable_http import streamablehttp_client
from mcp import ClientSession

async with streamablehttp_client("<YOUR_MCP_ENDPOINT>") as (r, w, _):
    async with ClientSession(r, w) as session:
        await session.initialize()
        await session.list_tools()  # self-describing: get schemas
        await session.call_tool("search_products", {
            "query": "warm winter jacket for hiking",
            "agent_id": "agt_your_agent_id"
        })

(Replace <YOUR_MCP_ENDPOINT> with the MCP URL from your developer dashboard.)

Option B: Integrating via REST API

If your agent isn't MCP-based, or you just want direct control, call the REST endpoints instead. The minimal request is close to a one-liner:

POST /api/v1/shopping/search
{
  "query": "a warm waterproof jacket for winter hiking",
  "caller": { "agent_id": "agt_your_agent_id" }
}

query is the only required field besides caller.agent_id — everything else is optional and simply makes results more precise. There's also a GET /api/v1/shopping/categories endpoint if you want to narrow results by category, and an equivalent set of endpoints for travel search.

What You Get Back

Every result — whether from MCP or REST — comes back with a ready-to-use, trackable purchase link (buy_url via MCP, affiliate_url via REST) alongside the normal display fields (title, price, rating, image). You hand that link straight to the user. There's no separate step to "activate" or "resolve" the link first — it's minted at search time. As a fallback, each result also includes an untracked link to the original product or destination page, in case a trackable link couldn't be generated for that specific offer.

Writing Good Queries

A few patterns make a measurable difference in result quality:

• Put context in query, not just a product name. Natural-language scenario and audience signals — "a gift for my wife who runs," "warm waterproof jacket for winter hiking" — drive better matching than a bare product term.
• Use specific terms in keywords, never bare nouns. ["women running shoes"] is a good keyword; ["shoes"] is not — a bare noun can match the wrong audience's version of a product (think: recommending men's shoes for a query about a gift for a woman).
• Pick a sorting approach on purpose. Use the intent preset for common cases — cheapest, best_discount, top_rated, or best_value — or fine-tune with explicit ranking dimensions (price, discount, commission rate, rating, review count, availability) if you need more control. If you specify neither, results default to best_value.
• Filter by price, platform, or stock status when relevant — all of that is optional but supported on both shopping and travel search.

Reliability & Performance

Typical end-to-end search latency is under 1 second at the 90th percentile (p90 < 1s), for both MCP and REST. Search is also built to degrade gracefully rather than fail outright: if vector-based matching is temporarily unavailable, it falls back to keyword search automatically; if there are genuinely no results, you get a clear "no results" status instead of an error; and offers without a valid purchase link are filtered out rather than handed to your agent as a dead end.

FAQ

Get Your agent_id