Using the Store Information API
This is a guide for fetching and updating a store's basic information (store name, store type, contact details, and address) via a REST API. You can implement a store information editing screen from token-authenticated clients such as staff apps.
Authentication
This uses the same authentication as fetching the store list. Attach Authorization: Bearer access-token (a user-scope token) to the request, and you must be a member of the target business account. No additional scope is required. If the target store does not belong to that business account, a 404 is returned.
Fetching a single store
Use this to populate the initial state of the editing screen.
GET /api/v1/me/organizations/{organizationId}/stores/{storeId}Example response (MeStore format, the same shape as each element in the store list):
{
"id": "store-id",
"name": "Shibuya Store",
"storeType": "Restaurant",
"primaryCategory": "...",
"status": "Active",
"address": {
"country": "JP",
"prefecture": "Tokyo",
"city": "Shibuya-ku",
"line1": "...",
"line2": "...",
"postalCode": "150-0001",
"latitude": 35.6,
"longitude": 139.7
},
"phone": "03-xxxx-xxxx",
"websiteUrl": "https://...",
"updatedAt": "2026-06-20T00:00:00Z"
}Updating store information
PUT /api/v1/me/organizations/{organizationId}/stores/{storeId}The editable fields are: store name (name), store type (storeType), primary category (primaryCategory), status (status), phone number (phone), website (websiteUrl), and address (postalCode / prefecture / city / line1 / line2 within address).
Partial updates are supported. Fields you do not specify (that are null) are left unchanged, and sending an empty string clears that field.
Example request:
{
"name": "Shibuya Main Store",
"phone": "03-1234-5678",
"websiteUrl": "https://example.com",
"address": {
"postalCode": "150-0002",
"prefecture": "Tokyo",
"city": "Shibuya-ku",
"line1": "Shibuya 1-2-3",
"line2": "Building 4F"
}
}The updated store information (the same MeStore format as when fetching) is returned. Your screen can re-render from this response.
Notes
- Even if you update the address, the server does not re-geocode (re-fetch latitude / longitude). country / latitude / longitude are preserved.
- Business hours, regular closing days, and working-hours limits are out of scope for this API. Use the Business Hours API instead.
- All fields not included in the request body (external IDs, POS integration information, etc.) are preserved.
Related pages
-
PosTransactionDto specification — field reference for transaction dataA complete field reference for PosTransactionDto, the canonical model for the transaction data ReceiptRoller handles. For each category — identifiers, dates, amounts, line items, payments, staff, status, and CRM linkage — it summarizes the field names, types, meanings, and how each POS vendor populates them. A reference for developers and external-system integrators. Also referenced from the Smaregi and Square mapping articles.
-
Purchase and receipt data integrationExplains the structure of the purchase and receipt data ReceiptRoller handles, how to retrieve it, related scopes, Webhooks, and common use cases.
-
Using the Business Hours APIA guide to ReceiptRoller's Business Hours API (/api/v1/stores/{storeId}/business-hours). Covers retrieving and updating per-day business hours, registering special business days (temporary closures and hour changes), configuring a store's workable hours (the upper bound for shift creation), and determining whether the store is currently open.
-
Using the Orders / OMS APIA guide to CRUD operations on the orders under a business account using ReceiptRoller's Orders / OMS API (/api/v1/orders). Covers creating, updating, transitioning status (confirm, process, cancel), and deleting orders, plus the flow for Android / iOS apps and server integrations.
-
Representative API examplesIntroduces, as curl commands, examples of calling the representative ReceiptRoller API endpoints (retrieving receipts, listing stores, creating products, registering Webhooks).