How to read the API reference and docs

ReceiptRoller's developer documentation has, broadly, four entry points by purpose. This help covers concepts and use cases; the exact spec of an endpoint is in the reference; and unresolved questions go to the community.

The four entry points

1. Developer help (this site)

The site you are reading now. It gathers concept explanations, implementation approaches, and per-use-case walkthroughs. It is not "the spec of a specific endpoint" but a way to know "how to build the whole thing".

• New here? Start with What you can do in the developer portal
• For which data domains are available, see Available data domains
• For the list of OAuth scopes, see OAuth scopes reference and availability
• For concrete implementation, go from the index to each guide

2. API top page

https://receiptroller.io/en/api/top

The top page of the ReceiptRoller API. It lists the commonly used, representative endpoints (the popular APIs) with simple samples.

• Use it like this — the entry point when you want to start in the fewest steps, e.g. "I just want to fetch transaction data" or "which endpoint gets user receipts?"
• Each endpoint shows its required scopes and a sample request
• If you need the detailed spec, you can jump from each endpoint to the reference in the next section

3. API reference (Swagger / OpenAPI)

https://receiptroller.io/docs/api/reference

The complete reference for all endpoints. It is generated from the OpenAPI (Swagger) spec, and you can check everything from parameters, the request body, the response body, to error codes.

• Use it like this — when confirming "can this parameter be omitted?", "what is the exact JSON structure of the response?", "what errors does this endpoint return?"
• It is organized by category (Store / CRM / SNS / Analytics / User / Survey, etc.)
• Each endpoint's required scopes are shown as badges
• The "Try it out" button lets you try a request directly from the browser (token required)

Getting the OpenAPI spec (the machine-readable file) directly

We publish the OpenAPI spec itself, which the reference is generated from, at the following URL.

https://receiptroller.io/openapi/v1.json

• Pass it to an AI coding assistant — just handing over this URL lets it read the endpoint spec and write call code or an API client
• Feed it into a code generator — you can auto-generate a typed client with openapi-generator, NSwag, Kiota, etc.
• Import into Postman / Swagger UI — you can pull it in as a collection and use it for behavior verification

Using Swagger efficiently

• Narrow by domain in the left sidebar — show only the relevant domain via tags such as Store / CRM / Analytics
• Keyword search — search across endpoint names, tags, and descriptions
• The schema section — inspect the object structures contained in responses independently
• Switching servers — you can switch environments such as production / staging via a dropdown

4. Developer community

https://receiptroller.io/en/developers/community

A community where you can ask and answer questions with other developers and the operating team. You can find questions the docs don't resolve, and whether other developers are stuck on the same thing.

• Before asking — search by keyword for existing questions. The same doubt may already be resolved
• How to post a question — Posting a question to the community
• How to receive answers — Receiving answers to your questions
• Answers from the operating team carry a "staff" badge
• Do not include confidential information (client secrets, access tokens, etc.) in the body

Examples of when to use which

In a real development flow, it is efficient to combine these.

• First encounter → read the use-case guides in the developer help (this site)
• Just want to try something → pick a popular endpoint from the API top page and try the sample
• Getting into real implementation → code while confirming the exact spec in the Swagger reference. When using an AI assistant, hand it openapi/v1.json
• Stuck on the spec → search the community for existing questions → post if there are none
• Before a production release → re-check "Operations and security" in the developer help

If the docs feel outdated

Because ReceiptRoller continuously adds features, occasionally the help and reference can diverge in wording. The source of truth for the spec is always the API reference (Swagger). If an actual response differs from what the help says, trust the reference side.

If you find an obvious error or have an improvement suggestion, let us know via the community or support.

Related guides

• What you can do in the developer portal (API and Webhook)
• Available data domains
• The flow to getting started
• OAuth scopes reference and availability
• Back to the developer help index