BlinkPay publishes its developer documentation and API specifications through a Model Context Protocol (MCP) server, so the AI assistant in your IDE can look things up while you build your integration, instead of you copying between a browser and your editor. It reads the same documentation you see on this site, so its answers are always current.
No account, API key or Client Portal login is needed. The server is retrieval only: it returns documentation and API schemas, and has no access to any payment, consent or account data.
| Setting | Value |
|---|---|
| Endpoint | https://merchants.blinkpay.co.nz/mcp |
| Transport | Streamable HTTP |
| Authentication | None |
Add the server from your project directory:
claude mcp add --transport http blinkpay-docs https://merchants.blinkpay.co.nz/mcp
To share it with everyone working on the project, commit a .mcp.json file at the root of your repository instead:
{
"mcpServers": {
"blinkpay-docs": {
"type": "http",
"url": "https://merchants.blinkpay.co.nz/mcp"
}
}
}
Add the server to .cursor/mcp.json in your project, or to ~/.cursor/mcp.json to use it in every project:
{
"mcpServers": {
"blinkpay-docs": {
"url": "https://merchants.blinkpay.co.nz/mcp"
}
}
}
Any client that supports the Streamable HTTP transport can connect with the endpoint above. Once connected, your client should list five tools from blinkpay-docs.
The server tells your assistant most of this when it connects. It is here so you can check it is being followed.
get_docs (api debit for Blink Payments, data for Blink Data), then use search_docs for follow-up questions. The documentation is small enough to read whole, and reading it whole surfaces the failure paths nobody thinks to search for. Without MCP, the same content is at /docs/debit/llms-full.txt and /docs/data/llms-full.txt.get_openapi_operation with sections set to request or responses returns only the part you need.Credential and Integration Security and Consent Experience for Direct Flows set out what BlinkPay expects of every integration: how to keep credentials out of apps and repositories, and what to show customers when you build your own consent screens. Asking it to check your integration against both pages before going live is a good use of the server.
You rarely need to call these yourself. Ask your assistant a question such as "Using the BlinkPay docs, how do I create a quick payment with the gateway flow, and what does the request body look like?" for Blink Payments, or "Using the BlinkPay docs, how do I create a Blink Data consent with the gateway flow and then list the customer's accounts?" for Blink Data, and it will choose the tools it needs.
| Tool | Returns |
|---|---|
get_docs | A product's full documentation as markdown, in parts |
list_docs | Every documentation page with its path, title, description and section |
search_docs | The best-matching documentation pages, ranked, each with its best section linked |
get_doc | One documentation page as markdown, exactly as published |
get_openapi_operation | The fully resolved schema of one API operation, or the list of operations |
Returns every page for api debit (Blink Payments and the shared pages), data (Blink Data and the shared pages) or all, in the order of the sidebar, as the same markdown the .md URLs serve. The result comes in parts of at most about 45 KB (roughly 17,000 tokens), so each fits within MCP clients' limits on a single tool result; each part says which part it is and how many there are, and the optional part argument (from 1) asks for the next one. A page is never split across parts unless it is larger than a part on its own.
{ "api": "debit" }
{ "api": "debit", "part": 2 }
Lists every page in sidebar order with its path, title, description and section (debit, data or shared). The optional api argument limits the list in the same way as search_docs.
{ "api": "data" }
Searches the documentation and returns the best-matching pages, one result per page, each with the path of its best-matching section (with the heading anchor), the headings above it, and a short snippet. It tolerates typos and partial words, so idempot finds idempotency. The optional api argument limits results to debit (Blink Payments) or data (Blink Data), each including the pages shared by both, or to shared alone, which helps when both products have a page of the same name.
{ "query": "idempotency key", "limit": 3 }
{ "query": "consent", "api": "debit" }
The first result for this query is /docs/shared/help/troubleshooting#idempotency-keys, which can be passed straight to get_doc.
Returns one page as markdown. It accepts a page path, the same path with .md appended, or a search_docs result path with its #anchor. The anchor is accepted but the whole page is always returned, so nothing around the matched section is lost; it is the same content as the page's .md URL. /docs/llms.txt returns the index of every page.
{ "path": "/docs/shared/flows/gateway-flow" }
Returns one operation from the OpenAPI specifications, with every $ref expanded so the complete request and response schemas are in one place. api is debit for Blink Payments or data for Blink Data; operation IDs repeat across the two, so it is required. Leave out operationId to list every operation of that API with its method, path and summary. The optional sections argument returns only the request (parameters and body) or only the responses, when the whole operation is more than you need.
{ "api": "debit", "operationId": "create-quick-payment" }
{ "api": "debit", "operationId": "create-quick-payment", "sections": "request" }
{ "api": "data" }
If your tools don't support MCP, append .md to any documentation URL to get the page as markdown, ready to paste into a prompt or fetch from an agent:
https://merchants.blinkpay.co.nz/docs/shared/flows/gateway-flow -> rendered page
https://merchants.blinkpay.co.nz/docs/shared/flows/gateway-flow.md -> markdown
/docs/llms.txt lists every page with its markdown URL, so an agent can find the right page without crawling the site. The whole documentation is also available as one file per product, at /docs/debit/llms-full.txt (Blink Payments and the shared pages), /docs/data/llms-full.txt (Blink Data and the shared pages) and /docs/llms-full.txt (everything).
The full OpenAPI specifications are published as YAML at /docs/debit/openapi.yaml (Blink Payments) and /docs/data/openapi.yaml (Blink Data), with no sign-in needed. The Resources page of the Client Portal renders the same specifications once you are signed in. Client libraries are on GitHub, and the Postman Collection covers trying requests by hand.
These limits apply only to this documentation server, not to the Blink Payments or Blink Data APIs; for how to handle the APIs' 429 responses, see Troubleshooting. The APIs' own rate limits are described under API Rate Limits.
Requests to the documentation server are limited per IP address, and the server may answer HTTP 429 with a Retry-After header; retry once that time has passed. Everyone behind the same office network address shares one allowance.