銷售管理 API（Orders / OMS API）的使用方式
這是使用 ReceiptRoller 銷售管理 API（/api/v1/orders）對商業帳戶底下的訂單進行 CRUD 操作的指南。彙整訂單的建立、更新、狀態轉移（確認、處理中、取消）、刪除，以及適用於 Android／iOS 應用程式或伺服器串接的流程。
交易一覽 API（Transactions API：POS＋OMS 整合摘要）的使用方式
ReceiptRoller 的 Transactions API 是將收銀營業額（PosTransactions）與銷售管理訂單（OmsOrders）整合為單一摘要的唯讀 API。在 Android／iOS 應用程式中一覽顯示「整個商業帳戶的交易」時，即為入口。
可利用的資料領域
以一覽說明可從 ReceiptRoller 的開發者入口取得的資料領域。彙整交易、商品、庫存、訂單、顧客、優惠券、SNS、廣告、個人使用者資料等，各領域含的內容與取得方法、必要的權限範圍。
Webhook 的登錄方法
解說在 ReceiptRoller 的開發者入口登錄 Webhook 端點的步驟、訂閱事件的選法、測試投放、多端點的分開運用、刪除與暫停的方法。
開發者入口可做的事
概觀 ReceiptRoller 的開發者入口可做的事。組合 REST API 的資料取得、操作與 Webhook 的即時事件接收，可從外部系統串接店鋪、使用者資料。
庫存管理 API（Inventory / WMS API）的使用方式
ReceiptRoller 庫存管理 API（Inventory / WMS API）的實作指南。解說以據點（倉庫、店鋪後場、賣場）為單位的庫存查詢、調整、異動紀錄取得方法，必要的 OAuth 權限範圍，Shopify 串接時的自動反映，以及從 MCP 工具（wms_get_stock / wms_adjust_stock 等）的使用方式。
店鋪向：以自家應用程式發行數位收據、以 Webhook 通知的指南
解說店鋪、品牌以自家應用程式向顧客發行數位收據，到以 Webhook 接收即時通知為止的步驟。涵蓋應用程式登錄、OAuth、Webhook 設定、簽章驗證。
OAuth 權限範圍一覽與利用可否
說明 ReceiptRoller 的 OAuth API 可利用的權限範圍的一覽，與各權限範圍被授予哪種類型的應用程式。也涵蓋 User 系權限範圍的審查要件、Store 系與 User 系無法混在的理由、從 LIFF 應用程式的利用方法。
商店應用程式 內容 API（公告、頁面、營業資訊）的使用方式
說明用於取得商店應用程式內容（公告、頁面、應用程式資訊清單、營業資訊、會員卡設定）的 /api/v1/apps/{shopId}/* 使用方式。解說 shopId 與商業帳戶 ID 相同、商業帳戶層級內容與店鋪層級內容的差異，以及驗證的處理方式。
店內媒體顯示器 API（Display API）的使用方式
ReceiptRoller 店內 Android 顯示器 API（/api/v1/displays/*）的概要，以及配對、心跳、播放清單取得、播放實績回報的步驟彙整。這是為在 Android 電子看板或店內數位看板端末播放媒體循環而實作應用程式的入門指南。
監視與失敗時的對應
解說 ReceiptRoller Webhook 的投放紀錄的檢視方式、應監視的指標與警報設計、無效信件的重新投放、常見故障模式與復原步驟。
利用目的、串接對象（POS／EC／分析等）的申告
解說在 ReceiptRoller 的開發者入口登錄應用程式時申告的「利用目的」與「串接對象類別」（POS／EC／分析／CRM／OMS／WMS／SNS／其他）的意義、選法、變更時的注意、與 User 系權限範圍審查的關聯。
PosTransactionDto 規格 — 交易資料的欄位參考
解說 ReceiptRoller 處理的交易資料正規模型 PosTransactionDto 的所有欄位。依識別碼、日期時間、金額、明細、付款、員工、狀態、CRM 串接各類別，彙整欄位名稱、型別、意義，以及各 POS 供應商的填入方式，是給開發者與外部系統串接負責人的參考。Smaregi、Square 雙方的對應文章也會參照本文。
原生行動應用程式指南：多商業帳戶存取與 OAuth 流程
Android / iOS 原生應用程式的實作指南。應用程式登錄時將「授權時將權杖關聯至 1 個商業帳戶」關閉，即會發行 user-scoped OAuth 權杖。以 /api/v1/me/organizations ＋ ?organizationId= 模式即可跨多個商業帳戶存取。
Webhook 的概要
解說 ReceiptRoller 的 Webhook 所投放的主要事件種類、應該使用 Webhook 而非輪詢的理由、投放形式（HTTPS POST + JSON）、投放保證的思考方式。