Skip to content
Amomic-AI

Use with coding agents

Connect these docs to Claude Code, Codex, Cursor, or any LLM so it writes your integration against the real contract.

If you are building this integration with a coding agent, give it the documentation first. An agent that has read the real contract writes working code on the first attempt; an agent guessing from a model's memory of "some WhatsApp API" invents endpoints that have never existed.

Everything on this page is public and needs no key.

The one-line version #

Pick whichever fits your tool:

Shell
claude mcp add --transport http amomic https://docs.amomic.in/mcp

The MCP endpoint

https://docs.amomic.in/mcp is the documentation MCP server. It exposes these pages as searchable resources so an agent can query them mid-task instead of ingesting the whole corpus up front. If your tool does not speak MCP, llms-full.txt gets you to the same place with a single fetch.

What is available #

/llms.txtcurated indexoptional

Every page with a one-line summary, organised by section. Small enough for any context window. Start here.

/llms-full.txtcomplete corpusoptional

The entire documentation set in one plain-text file, in reading order. One fetch and the agent knows everything.

<page>.mdraw markdownoptional

Any page, plus .md. /api/calls → /api/calls.md. No navigation, no HTML, no chrome.

/openapi.jsonOpenAPI 3.1optional

The machine-readable API contract, generated from the running service. Feed this to a client generator or an agent that speaks OpenAPI.

/mcpMCP serveroptional

Live documentation search over Model Context Protocol, for agents that support it.

Set it up properly #

  1. 1

    Give the agent the entry point

    Whatever tool you use, the first thing it needs is a URL it can fetch. In a prompt, this is enough:

    Text
    Read https://docs.amomic.in/llms-full.txt — that is the complete Amomic-AI
    documentation. Use it as the source of truth for endpoints, request shapes,
    and error codes. Do not guess at any API surface it does not describe.

    That last sentence matters more than it looks. Without it, an agent that cannot find something tends to invent a plausible endpoint rather than tell you it does not exist.

  2. 2

    Pin it in your repository

    Add the pointer to your repo so every future session starts informed, rather than you re-pasting the URL each time.

    AGENTS.md
    # Amomic-AI integration
    

    This service sends WhatsApp messages and places AI voice calls through
    Amomic-AI.
    

    **Documentation:** https://docs.amomic.in
    - Full corpus for ingestion: https://docs.amomic.in/llms-full.txt
    - Any page as markdown: append `.md` to its URL
    - OpenAPI contract: https://docs.amomic.in/openapi.json
    

    **Rules for this integration**
    - The public API is `https://services.amomic.in/api/v1`. Server-side only —
      it sends no CORS headers, so it must never be called from browser code.
    - Auth is `Authorization: Bearer amk_live_…`, from a secret store. Never a
      literal in source, never in the front end.
    - Every POST that spends money (`/messages`, `/calls`, `/tickets`) must send
      an `Idempotency-Key` derived from our own record id, so a retry cannot
      double-send.
    - Errors are `{"error": {code, message, details, request_id}}`. Branch on
      `error.code`, then `error.details.reason`. Log `request_id`.
    - WhatsApp free-form text only works inside the 24-hour window. Outside it,
      send an approved template or the API returns 409.
    - Phone numbers must match `^\+?\d+$` — no spaces, dashes, or brackets.

    The same file works as CLAUDE.md, .cursorrules, or whatever your tool reads. The content is what matters, not the filename.

  3. 3

    Give it the OpenAPI contract for exact shapes

    Prose is good at why; a schema is better at exactly which fields. For request and response shapes, point the agent at the contract:

    Shell
    curl https://docs.amomic.in/openapi.json

    It is generated from the running service, so it cannot drift from what the API actually accepts.

  4. 4

    Check its work against the real thing

    The fastest way to catch a hallucinated endpoint is to call the API. GET /ping is free, has no side effects, and confirms auth, environment, and scopes in one response:

    Shell
    curl https://services.amomic.in/api/v1/ping \
      -H "Authorization: Bearer $AMOMIC_API_KEY"

    If an agent has written code against an endpoint that does not exist, this is where you find out — in seconds, not in production.

Per-page hand-off #

Every page here has a Copy for LLM button in its top-right corner.

  • Click it to copy that page as clean markdown, ready to paste.
  • Open the dropdown to send the page straight to Claude or ChatGPT with the canonical URL already in the prompt, or to grab the raw .md file.

For a focused task — "implement webhook verification" — one page is better context than the whole corpus. Sending less, and sending exactly the right part, produces better code.

Getting good results #

Name the constraint, not just the goal

"Send a WhatsApp order update" gets you a request. "Send a WhatsApp order update that survives a retry and handles the closed-window case" gets you the Idempotency-Key and the template fallback — both of which are in the docs, and neither of which the agent will reach for unless you say the words.

A few things worth telling any agent up front, because they are the mistakes that survive review:

  • This API is server-side. There are no CORS headers on /api/v1. If the generated code calls it from a React component, it will fail in the browser and the fix is architectural, not a header.
  • 201 on a call means ringing, not connected. Outcomes arrive later, by polling or by the call.ended webhook. Code that treats the 201 as success will report every unanswered call as a win.
  • Verify webhooks against the raw request body. Parsing the JSON and re-serialising it changes the bytes and the signature will not match. This is the single most common webhook bug, in every language.
  • Nothing is versioned behind a header. There is one namespace, /api/v1. If an agent writes Accept-Version or /api/v2, it is inventing.

Where the risk actually is #

Documentation makes an agent accurate about our API. It does not make it careful about your system. Two things still need human eyes:

  • Where the key lives. An agent will happily commit a working key into a config file because the code runs afterwards. Keys belong in a secret manager, and a leaked one should be rolled immediately from the console.
  • Who gets contacted. Code that loops over a customer table and calls POST /messages is trivial to generate and expensive to get wrong. Rate limits will slow it down; they will not tell you that you just messaged the wrong segment.

Review those two by hand, every time. The rest of the integration is exactly the kind of work an agent should be doing for you.