AI coding assistants can shorten an integration only when they work from precise, current source material. We have rebuilt the public CoinsSend API documentation so developers and compatible coding agents can use the same reviewed contract, examples, and security guidance.
The release combines a public read-only MCP server, a canonical OpenAPI 3.1 document, an LLM-friendly documentation index, request-signature test vectors, and stronger automated checks. It makes it faster to explore the API and prepare integration code while keeping credentials and payment operations under the developer's control.
One reviewed source for developers and agents
The new documentation layer gives each tool the format it handles best:
- MCP for coding agents. A compatible client can search the public documentation, retrieve an exact page, inspect an OpenAPI operation, or load a component schema.
- OpenAPI 3.1 for tooling. The public contract can support code generation, validation, API exploration, and integration tests.
- llms.txt and a documentation manifest. Agents that do not use MCP can discover the canonical public pages without crawling unrelated content.
- Executable signature test vectors. Teams can verify canonical JSON, legacy MD5 signatures, and timestamped HMAC withdrawal signatures against published fixtures.
- Server-side examples and guarded prompts. The docs include PHP, JavaScript/Node.js, and Python examples, plus prompts for checkout, webhook, and production-hardening tasks.
The OpenAPI contract intentionally covers a reviewed set of public operations rather than exposing internal application routes. That boundary keeps the machine-readable surface useful and auditable.
Connect a coding agent in minutes
The remote documentation server is available at https://api.coinssend.com/v1/docs/mcp. For example, Codex users can add it with:
codex mcp add coinssend-docs --url https://api.coinssend.com/v1/docs/mcpNo CoinsSend API key is required for this connection because the server provides public documentation only. Other compatible MCP clients can use the same endpoint according to their own connection flow. The full setup notes are available in the MCP guide.
What an agent can help with
After the documentation server is connected, a coding agent can:
- search for the relevant workflow, such as invoices, static wallets, webhooks, withdrawals, fees, balances, or coin rates;
- retrieve the exact public documentation page instead of relying on a broad web search;
- look up an operation by
operationIdand inspect its request, response, authentication, and error schemas; - use published signature fixtures to test the application's signing implementation;
- draft server-side integration code and tests for an engineer to review and run.
If you are deciding between payment models before implementation, our guide to static wallets and invoices explains the product trade-offs. The agent-ready docs then provide the exact API contract for the selected path.
A clear security boundary
The MCP server is read-only. It cannot create an invoice, generate a wallet, initiate a withdrawal, access a merchant account, or receive merchant credentials. Its tools are limited to a reviewed public documentation corpus and are designed to be non-destructive and idempotent.
Integration code still belongs on a trusted server. Keep merchant keys in protected environment variables or a secret manager, sign requests server-side, verify webhook signatures against the raw request body, and review generated code before executing it. Write requests should follow the documented retry behavior; they should never be retried blindly.
OpenAPI, test vectors, and direct access
The same source material is available without MCP:
- OpenAPI 3.1 contract for machine-readable operations and schemas;
- llms.txt for a compact agent-oriented index;
- documentation manifest for the canonical public corpus;
- signature test vectors for interoperable signing checks;
- AI integration prompts for structured implementation and review tasks.
This means a team can use an MCP-enabled agent, import OpenAPI into its existing toolchain, or work directly from the documentation while keeping the same source of truth.
Checks that keep the contract aligned
Documentation changes now pass automated consistency checks, OpenAPI linting, breaking-change detection, and runtime contract tests that compare the published specification with the actual public routes, controllers, and middleware. Separate tests cover the MCP server, documentation corpus, request signatures, and the managed OpenAI Vector Store synchronization used by the CoinsSend docs assistant.
The synchronization flow stages and verifies a new public corpus before retiring the previous managed files. Locking, pagination, timeouts, ownership checks, and cleanup reduce the chance of publishing a partial or unintended corpus.
Start with the workflow, then verify the details
Open the getting-started guide, connect the documentation server if your coding agent supports MCP, and describe the payment flow you want to build. Ask the agent to cite the exact documentation page, OpenAPI operation, and schema it used. Then review the result, run the signature fixtures and tests, and validate the integration in your own environment.
This release does not turn payment integration into an unreviewed one-click action. It gives developers and their tools a faster, more reliable way to reach the correct contract and build against it.
