Endpoints and versioning

Base URL

Production: https://api.receiptroller.io/v1
Staging:    https://api-staging.receiptroller.io/v1

The OAuth authorization endpoints are on a separate host.

Authorize: https://receiptroller.io/oauth/authorize
Token:     https://receiptroller.io/oauth/token

URL structure

/v{version}/{resource}[/{ID}][/{subresource}]

Examples:
GET  /v1/receipts                  ← list receipts
GET  /v1/receipts/rcp_xyz123       ← individual receipt
GET  /v1/receipts/rcp_xyz123/items ← a receipt's line items
POST /v1/products                  ← create a product

Versioning policy

• We use the URL path scheme (/v1/...). We do not use a header scheme
• Backward-compatible changes (such as adding a field) are made within the same version
• Breaking changes (removing a field, changing a type, changing a URL) are provided as a new version (/v2)
• After a new version is released, the old version runs in parallel for at least 12 months

Changes considered backward-compatible

• Adding a new field to a response
• Adding a new endpoint
• Adding an optional request parameter
• Adding a new code to an existing error code set

When implementing your client, building it to ignore unknown fields makes it easier to maintain compatibility.

Examples of breaking changes

• Removing or renaming an existing field
• Changing a field's type (string → number, etc.)
• Adding a required request parameter
• Changing the authentication scheme
• A large reduction in the rate limit

Deprecation notice and support period

Deprecation notices are communicated via the developer portal's "Announcements", email, and the Sunset header.

Checking the current version

The X-RR-Api-Version response header contains the version that processed the current request.

HTTP/1.1 200 OK
X-RR-Api-Version: 2026-04-01
Content-Type: application/json

Related guides

• The basics of requests and responses
• Error codes and retry guidance
• How to read the API reference and docs
• Back to the developer help index