Machine-readable docs
Four artefacts, rebuilt on every deploy from the same pages you are reading. Use them instead of scraping the HTML — scraped pages arrive with nav chrome, and code fences do not survive the trip.
| What | Where | For |
|---|---|---|
| One page as Markdown | any page + .md |
Pasting one endpoint into a model |
| Index of every page | /llms.txt |
Letting an agent fetch only what it needs |
| The whole corpus | /llms-full.txt |
One paste, whole API in context |
| OpenAPI 3.1 | /openapi.json |
Client generators, Postman, Insomnia |
Any page, as Markdown
Swap .html for .md:
https://partners.niftipay.com/api/withdrawals/create.html ← what you read
https://partners.niftipay.com/api/withdrawals/create.md ← what you paste
Every page also carries Markdown and Copy buttons in the top right. Copy puts the raw Markdown on your clipboard.
/llms.txt and /llms-full.txt
/llms.txt follows the llmstxt.org
convention: a short summary and every page as a link, grouped. Hand it to an
agent that can fetch, and it pulls the one page it needs rather than the whole
site.
/llms-full.txt is everything concatenated, ordered the way
the sidebar is — so a model reading top to bottom meets authentication before it
meets withdrawals. Around 125 KB, which fits comfortably in a modern context
window.
curl -s https://partners.niftipay.com/llms-full.txt > niftipay-partner-api.md
/openapi.json
OpenAPI 3.1, generated from these pages. Carries paths, methods, summaries,
path and query parameters, bearer security, the request and response examples
printed on each page, and x-required-scopes per operation.
npx @openapitools/openapi-generator-cli generate \
-i https://partners.niftipay.com/openapi.json -g typescript-fetch -o ./niftipay
What it deliberately does not contain
Field-level JSON Schemas for request bodies. The reference describes fields in prose tables, and machine-reading those would produce a schema that looks authoritative and is not — which is worse than none, because a client generator would emit types from it without hesitating.
For the one place a field-level contract genuinely exists, use the API itself:
GET /api/v1/partner/onboarding/schema
That returns the KYB field set as data — every enum inline, required_at_submit
per field, repeating groups with their shapes. See
Onboarding schema.
So: openapi.json is the surface map, /onboarding/schema is the field
contract. Neither is a substitute for the other.
Versioning
openapi.json carries info.version, and llms.txt states a docs version.
Both are dates. They move when the docs are rebuilt, which is not the same as
the API changing — the API’s own contract version is api_version, returned on
every response, and that is the one to pin behaviour to.