Overview

Last updated: July 6, 2026 · Covers Loyverse API v1.0 · Base URL: https://api.loyverse.com/v1.0/ The most common Loyverse API pitfalls are scope-and-limit surprises. The Loyverse API is read-mostly: you can read almost every point-of-sale object but create only a limited set. Receipts older than 31 days can return 402 unless Unlimited Sales History is enabled, a receipt created with POST can hold only one payment type, you cannot create open orders or tickets for the kitchen display, item updates use POST (not PUT), and a 403 is often a request problem rather than a bad token. This guide explains each of these, with the exact endpoints and status codes, so you can find the answer without opening a support ticket. Why does my Loyverse API token return 401 or “access token is not valid”? The Loyverse API returns 401 Unauthorized (apps often show this as “access token is not valid”) when the token was regenerated or deleted, the Authorization header is malformed, or the wrong value was pasted. Deleting or regenerating a token in the Back Office suspends the old value immediately, so any integration still using it breaks until updated — a recurring cause of sudden 401s. Check, in order: the header is exactly Authorization: Bearer <token> with one space after Bearer and no quotation marks; no leading/trailing whitespace or newline was copied with the token; the token still exists under Settings → Access Tokens; and you are calling https://api.loyverse.com/v1.0/. If you rotate a token, update every integration in the same change window. Why can’t I read receipts older than 31 days from the Loyverse API? By default the Loyverse API returns sales data only from the last 31 days. The Loyverse Help Center states that access to sales data is limited to the last 31 days unless you start a trial of, or subscribe to, the Unlimited Sales History add-on. When an integration requests receipts older than that window without the add-on, the request returns 402 PAYMENT_REQUIRED rather than an empty list. This is the most common “I created a token but cannot pull my data” case, and the cause is the account plan, not the code. To read older receipts, enable Unlimited Sales History in Settings → Billing & Subscriptions (a 14-day free trial is available). Confirm you are inside the allowed window with date filters: GET https://api.loyverse.com/v1.0/receipts?created_at_min=2026-06-06T00:00:00.000Z&limit=250 Authorization: Bearer YOUR_ACCESS_TOKEN A 402 here is a subscription signal, not a bug — check the date range and whether the add-on is active before debugging the request. Can I create sales, receipts, and orders through the Loyverse API? Partly. You can create a completed sales receipt with a POST to /v1.0/receipts, but a receipt created this way can carry only one payment type. The API reference states there is a restriction that “only one payment can be applied to receipt when using POST request,” — so split-tender (multiple payment methods on one receipt) cannot be created through the Loyverse API. You also cannot post a receipt with a GET request; creation is POST only. Separately, you cannot create open orders or open tickets through the Loyverse API. Creating orders via the API so they appear on the Loyverse Kitchen Display System (KDS) is not possible. If your app takes online or in-app orders, the API will not route them to the POS or KDS as live tickets. Plan for this early: design each API-created receipt around a single payment type, and do not build a workflow that depends on pushing open tickets into the POS. How do I create or update items, and why do I get 405 Method Not Allowed? Use POST, not PUT, and post to the collection, not to an item URL. The /v1.0/items endpoint supports GET and POST only. To create an item you POST to /v1.0/items; to update one you POST to the same /v1.0/items with the item’s id in the request body. Sending PUT /v1.0/items, or POST to /v1.0/items/{id}, returns 405 Method Not Allowed. This trips up developers whose HTTP client or framework defaults to PUT for updates. POST https://api.loyverse.com/v1.0/items Authorization: Bearer YOUR_ACCESS_TOKEN Content-Type: application/json { "id": "EXISTING_ITEM_ID", "item_name": "Latte" } // include id to update; omit id to create One more item-creation caution: you cannot set an item’s initial stock in the same call that creates the item. Create the item first, then set stock levels through the inventory endpoint as a separate step. How does pagination work in the Loyverse API, and why did I only get 50 records? The Loyverse API uses cursor-based pagination, and the default page size is small. The default limit is 50 objects and the maximum is 250. List responses include a cursor; to get the next page you pass that value back as the cursor query parameter. If you read only the first response you silently receive at most 50 (or 250) rows and assume the rest are missing. GET /v1.0/receipts?limit=250 -> read receipts, capture "cursor" GET /v1.0/receipts?cursor=<cursor_from_previous_response> -> repeat until no cursor is returned Keep the same filters across the whole cursor sequence — let the cursor drive paging. What are the Loyverse API rate limits? The Loyverse API is rate limited and returns 429 Too Many Requests when you exceed it. The limit is 300 requests per 300 seconds; when you hit a limit, back off and retry with increasing delays rather than looping immediately. Reduce request volume by paginating with limit=250, requesting only the date ranges you need with created_at_min/created_at_max, and caching reference data (categories, items, payment types) instead of refetching it on every run. How do webhooks work, and what breaks webhook verification? There are three ways to create webhooks in Loyverse. From https://r.loyverse.com/dashboard/#/webhooks From /webhook endpoint using an access token. From /webhook endpoint using OAuth 2.0. Only webhooks created by the third method include X-Loyverse-Signature in the header. We use the SHA-1 HMAC algorithm with hex encoding as the hash function. How do I get the sold items (line items) for each receipt? There is no separate “line items” or “invoice details” endpoint in the Loyverse API — the items sold are embedded inside each receipt object as its line_items field. To get every item sold in a period, request the receipts for that period and read line_items from each receipt in the response. GET https://api.loyverse.com/v1.0/receipts?created_at_min=2026-06-01T00:00:00.000Z&created_at_max=2026-07-01T00:00:00.000Z&limit=250 Authorization: Bearer YOUR_ACCESS_TOKEN Each receipt in the response carries its own line_items (the items sold on that receipt), alongside totals, taxes, payment, and customer references. Use created_at_min/created_at_max to bound the period, and follow the cursor to page through all receipts. If you need per-item sales analysis, flatten line_items across receipts on your side — the Loyverse API does not offer a pre-aggregated “sales by item” endpoint. What is a Variant ID in the Loyverse API? A Variant ID (variant_id) is the internal identifier — a UUID — of one specific variant of an item. In Loyverse API structure, every item has at least one variant, even if an item doesn’t have variant in the Back office. You will not find the ID by browsing the Back Office item card — read it from the API. Get variant_id values from the items endpoints: each item returned by GET /v1.0/items includes its variants, and each variant carries its variant_id. This matters because two core operations key on the variant, not the item: inventory levels are tracked per variant per store, and receipt line_items reference the variant that was sold. If your integration maps products by item ID alone, it cannot address stock or reconcile sale lines for items. How do I increase or decrease stock through the Loyverse API? Update stock with a POST to /v1.0/inventory (batch update of inventory levels), and note the most important detail: stock_after is the new absolute stock level, not the amount to add or remove. To reduce stock by 3 from a level of 13, you send stock_after: 10 — not -3. Sending a delta silently sets the stock to that delta value, which is the classic way integrations corrupt their stock counts. POST https://api.loyverse.com/v1.0/inventory Authorization: Bearer YOUR_ACCESS_TOKEN Content-Type: application/json { "inventory_levels": [ { "variant_id": "YOUR_VARIANT_ID", "store_id": "YOUR_STORE_ID", "stock_after": 10 } ] } Because stock_after is absolute, a decrease is always read-then-write: fetch the current level from GET /v1.0/inventory for that variant_id and store_id, compute the new level, and post it. This applies equally when calling the Loyverse API from no-code tools such as Make, Zapier, or n8n — add an HTTP module, perform the read step first, and be aware that between your read and your write a sale at the POS can change the level (re-read or reconcile periodically if exact counts matter). Also remember the item-creation order of operations: you cannot set initial stock in the call that creates an item — create the item first, then set its level through /v1.0/inventory. Can I connect a payment provider through the Loyverse API? The Loyverse API does not connect payment providers to the POS checkout. The API does not add it to the sale screen. What the API does allow is building your own integration around the sale: you can record a completed sale by posting a receipt (with a single payment type), and you can read receipts, items, customers, and inventory to sync with an external system. Plan the boundary accordingly: taking the payment happens in your own app or the provider’s system; the Loyverse API’s role is recording the resulting sale and keeping catalog, stock, and customer data in sync. Can I read Time Clock (timecard) data through the Loyverse API? Time Clock data — employee clock-in and clock-out records — is not currently exposed through the Loyverse API. The Employees resource covers employee profiles, but there is no endpoint for retrieving timecards, so payroll or attendance integrations cannot pull working hours automatically today. Which resources does the Loyverse API expose? The Loyverse API (v1.0) exposes the core point-of-sale objects as REST resources. Reads are broad; writes are limited (see the sections above). Confirm exact fields and any new resources against the API reference, since the list evolves. You want to… Resource(s) Note Read or sync the catalog Items, Variants, Categories, Modifiers, Discounts Update objects via POST (id in body); no PUT Read sales / bills Receipts POST creates a receipt with one payment type Read or adjust stock Inventory Set stock separately after creating an item Sync customers / loyalty Customers — Map structure and staff Stores, Employees, Payment Types, Merchant React to changes Webhooks Quick reference: where the data actually lives You are looking for… It lives in… Key detail Items sold per sale (“invoice lines”) line_items inside each receipt No separate line-items endpoint; filter receipts by created_at One specific receipt GET /v1.0/receipts/{receipt_number} Use the receipt_number value exactly. Stock levels GET/POST /v1.0/inventory Per variant_id per store_id; stock_after is absolute Variant identifiers Variants inside GET /v1.0/items Every item has ≥1 variant Employee timecards Not in the API Back Office reports only; employee profiles are available, hours are not Frequently asked questions Can I create a sale or receipt through the Loyverse API? Yes, with a POST to /v1.0/receipts, but the receipt can have only one payment type — split payments cannot be created via the API. Can I push orders to the POS or Kitchen Display via the API? No. Creating open orders or tickets via the API to appear on the KDS is not possible at this time. Why do I get 405 when updating an item? Because /v1.0/items accepts only GET and POST. Update an item by POST-ing to /v1.0/items with its id in the body; do not use PUT or post to /v1.0/items/{id}. Why can I only read the last 31 days of receipts? By default the API limits sales data to the last 31 days. Reading older receipts requires the Unlimited Sales History add-on (14-day trial available); without it, older requests return 402. Why did a list request return only 50 records? The default page size is 50. Set limit up to 250 and follow the cursor in each response to page through the full result set. Is there a line-items or invoice-details endpoint in the Loyverse API? No. The items sold are nested inside each receipt as line_items. Request receipts for your date range and read line_items from each receipt object. How do I get all items sold in a specific period? Call GET /v1.0/receipts with created_at_min and created_at_max, follow the cursor through all pages, and flatten the line_items of each receipt on your side. What is variant_id and where do I find it? The UUID of one specific variant of an item, assigned by the system. Read it from the variants inside GET /v1.0/items; inventory and sale lines are keyed on it. How do I add or subtract stock via the API? You don’t add or subtract — you set. POST /v1.0/inventory with stock_after as the new absolute level. Read the current level first, compute, then write. Can the API add a new payment provider to the POS? No. The API records completed sales (one payment type per API-created receipt) and syncs data; charging on the POS with a new provider cannot be done by an API call. Can I pull employee working hours via the API? Not currently. Timecard data is available in Back Office reports but has no API endpoint; employee profiles are available via the Employees resource.

Hello Loyverse team, We'd like to list LoyverseGo in the App Marketplace. It's a Telegram delivery suite for Loyverse merchants: a customer mini app (live menu from the Items API, delivery or pickup, courier tracking on a map), a courier bot (order cards, routes, statuses), and a dispatcher board. Every order is written back to Loyverse as a receipt via the Receipts API, so sales and stock stay correct. The OAuth app is live (App ID LTN6lbybnmpaJ67Awh1Q) with active installs. Scopes: MERCHANT_READ, ITEMS_READ, RECEIPTS_READ/WRITE, CUSTOMERS_READ, STORES_READ, PAYMENT_TYPES_READ. Tokens are stored encrypted and refreshed automatically. Landing: https://poster.rayndev.shop/loyverse Privacy: https://poster.rayndev.shop/loyverse/privacy Terms: https://poster.rayndev.shop/loyverse/terms Demo video: https://youtu.be/qbdcVVjQyjs Happy to provide the logo, screenshots and anything else needed for review. Thank you!

hi any news regarding the application?

Hello @Stash Thank you for your interest in listing an app in the marketplace. I will send you a DM.

Hi Loyverse team, We run multi-branch retail on Loyverse ourselves — and built Atlas to answer the questions our CSV exports couldn't keep up with: where's cash stuck in dead stock, what to move between branches, what's about to run out, and where the numbers look off. It's been running on our own live stores, and we'd like to share it with other Loyverse merchants. Atlas (https://app.atlasth.com) is a read-only inventory-analytics app for Loyverse retailers, built especially for multi-branch shops. It turns your Loyverse sales and stock into one dashboard: inventory value & dead-stock cash, reorder & clearance suggestions, cross-store rebalancing, loss-prevention flags (unusual refunds / discounts / voids + inventory shrinkage), and product-expiry tracking. It's registered as a developer app and the OAuth connect is live and tested: • App ID: W_33DIy8RW8omkyxmDgr • Read-only scopes only: RECEIPTS, ITEMS, INVENTORY, STORES, MERCHANT • We never write to Loyverse data. Live app: https://app.atlasth.com · Privacy: https://app.atlasth.com/privacy.html · Terms: https://app.atlasth.com/terms.html What's the process to get it listed in the App Marketplace, and what assets/details do you need? Logo, description, and screenshots are ready to send. Thanks! Goya — Greenstead Co., Ltd. (Thailand) · greenstead-th.com

Hello Karthik, Let us continue communication via email. Thank you.

Last reviewed: June 2026. The material below is for general information only and should not be treated as legal or tax advice — verify how the rules apply to your own situation with Panama's Dirección General de Ingresos (DGI) or a licensed local tax professional. The short version Meeting Panama's electronic invoicing requirements comes down to a handful of non-negotiables: every taxpayer in scope has to generate each invoice as a digitally signed XML file inside the Panama Electronic Invoicing System (SFEP), get that file cleared before the customer ever receives it, and then hand over a readable receipt stamped with a unique validation code. The rules tightened on January 1, 2026: a company that invoices above B/. 36,000 a year, or that produces more than 100 invoices in a single month, is no longer eligible for the DGI's free tool and has to switch to a Qualified Authorized Provider (Proveedor Autorizado Calificado, or PAC) or run its own DGI-certified platform. Three instruments form the backbone of all this — Executive Decree 766 of 2020, Law 256 of 2021, and Resolution 201-6299 of 2025. Developers face a parallel checklist. A point-of-sale product reaches compliance by building valid XML, signing it with a qualified electronic signature, sending it to a PAC to be authorized, handing the resulting code and printable receipt back to the merchant, and storing everything. One clarification worth making early: Loyverse POS does not issue Panamanian electronic invoices by itself. Instead, the Loyverse App Marketplace offers a third-party connector from AlphaPOS that pulls in each sale and forwards an electronic invoice to the tax authority. What exactly is the SFEP, Panama's e-invoicing platform? The SFEP — short for Sistema de Factura Electrónica de Panamá — is the country's official platform for creating, clearing, and storing electronic tax documents. It is operated by the DGI, the tax administration that sits under the Ministry of Economy and Finance. Once a document has been authorized inside the SFEP, the resulting electronic invoice is a digitally signed file that carries exactly the same legal force as a printed one. Panama follows what is known as a clearance (or pre-validation) approach. The practical consequence is straightforward: no sale becomes a legally valid invoice until the document has first been cleared upstream. Emailing a customer an ordinary PDF, or scanning a paper bill, simply does not count. Strip away any of the four essentials — structured XML, a digital signature, validation, and the unique code — and the document carries no fiscal weight at all. Which laws and resolutions govern e-invoicing in Panama? A stack of statutes and administrative resolutions underpins the obligation: Executive Decree 766 of 2020 — set up the operational foundations of the SFEP. Law 256 of 2021 — recognized PAC-validated electronic documents as a legitimate means of fulfilling tax duties and empowered the DGI to run the system. Resolution 201-7569 (2022) — created the basis on which the DGI started certifying PAC providers. Resolution 201-0384 (2024) — brought further groups into the net, among them state suppliers and political organizations, requiring them to log income and expenses solely through the SFEP. Resolution 201-6299 (2025) — the measure that, from January 1, 2026, narrowed eligibility for the free tool and moved larger-volume taxpayers to a PAC. Who must issue electronic invoices today? Rather than switching on overnight, the requirement has rolled out group by group. As things stand, these taxpayers are covered: Any new tax ID (RUC) registered from January 1, 2022 onward. Vendors that sell to government bodies, the Panama Canal Authority included. Taxpayers the DGI has designated as large or verified. Self-employed professionals and service providers — lawyers, accountants, and architects among them. Companies based in special economic areas such as the Colón Free Zone, the City of Knowledge, and Panamá Pacífico. Banks, insurers, and other financial entities. Any business that now exceeds the 2026 volume limits described further down, which is obliged to invoice via a PAC. Not captured by any of these yet? It is wiser to read your situation as "not yet" rather than "never" — the DGI has stretched the perimeter a little wider every year since the program began. How does a merchant get compliant, step by step? For a merchant, getting compliant follows a fairly predictable order: Sign up with the DGI and make sure your RUC stays accurate and up to date. Secure a qualified electronic signature certificate — the Firma Electrónica Avanzada (FEA) — issued by a provider accredited by the National Directorate of Electronic Signatures. Register inside the SFEP as an authorized issuer. Pick your issuing channel: the DGI's free tool while you remain under the caps, or a PAC once you pass them or want to connect your accounting. Emit documents that conform to the prevailing technical specification (the ficha técnica) — the prescribed XML layout, all required fields, tax elements like the ITBMS, and the formatting rules. A single invoice can hold as many as 1,000 line items. Release only documents that have been authorized. Since nothing is fiscally valid until it clears validation, never give a customer a file that has not. Keep every record. Retain the signed XML alongside its readable receipt — most businesses store them for a minimum of five years to cover audits. Should you use the free tool or a PAC? Criterion Facturador Gratuito (free tool) Qualified Authorized Provider (PAC) Who it suits Taxpayers with low volume Higher-volume operations and integrations Yearly income ceiling (from Jan 2026) Up to B/. 36,000 None Monthly document ceiling (from Jan 2026) Up to 100 None POS / ERP integration Keyed in manually Supported through the provider Pricing Supplied free by the DGI A paid, commercial service Who validates The DGI The PAC validates and authorizes What changed on January 1, 2026? If one rule is going to force businesses to change how they invoice, it is Resolution 201-6299. From January 1, 2026, the free invoicing tool is reserved for taxpayers whose billing stays at or below B/. 36,000 per year and who issue 100 or fewer invoices per month. Step over either line and you are required to adopt a PAC or stand up your own DGI-certified invoicing platform. Because the free service had been the default for thousands of small firms and independent professionals, many now need a sturdier arrangement — so the sensible move is to watch your rolling totals and migrate ahead of the limit instead of waiting until you breach it. How does an invoice move through validation? (CUFE, CAFE, FEA) Knowing how a document travels from creation to approval is what makes it possible to build — or shop for — a compliant tool. The journey looks like this: Creation — the issuing software writes the invoice as structured XML. Signing — the issuer attaches the qualified electronic signature (FEA) drawn from an approved certificate. Sending — that signed XML is transmitted to a PAC (or the DGI tool) to be checked against the technical standard. Approval — the PAC validates the document and clears it for use. Unique code (CUFE) — the platform issues the Código Único de Factura Electrónica, the identifier that allows anyone to confirm the invoice with the DGI. Readable receipt (CAFE) — a printer-friendly version, normally a QR-bearing PDF, is generated for the buyer. The framework also anticipates problems. Credit and debit notes exist to fix invoices after they have been issued, and a contingency mode keeps the tills running through technical outages, queuing the documents for validation as soon as the connection is back. What does a POS developer have to build? Building point-of-sale software for Panama means treating compliance as real engineering rather than a tick-box. The bare minimum your product has to do: Generate XML that conforms to the DGI's current ficha técnica — every mandatory field, the ITBMS tax breakdowns, and the line-item structure (up to 1,000 entries). Sign each document using the merchant's FEA certificate. Talk to a PAC for the clearance exchange — or, to issue on your own, obtain DGI certification for your platform. Grab and persist the CUFE handed back on authorization, and draw the CAFE with its QR code so a cashier can print or send it. Wire up credit- and debit-note handling plus a contingency path, so neither corrections nor downtime break compliance. Translate POS data into the correct invoice fields — items, prices, customer identity, taxes, and payment methods all have to land in the right XML elements. Store the records for the mandated retention period and keep them retrievable for audits. In practice, plugging into a PAC that already holds authorization tends to be the more sensible path for most teams than chasing certification directly, because the PAC already owns the validation step and the DGI connection. Where does Loyverse fit in? Loyverse is a cloud point-of-sale system, and it does not generate Panamanian electronic invoices on its own. What it offers for Panama instead is a marketplace listing: a third-party integration created by AlphaPOS (Soluciones Técnicas Alpha S.A.), filed under the e-invoicing category with a free plan on offer. The marketplace listing describes the integration this way: It links Loyverse to the tax authority. The app reads sales out of Loyverse and automatically builds and transmits electronic invoices to the tax authority, leaving staff to ring up sales exactly as they always have. It sets out a defined data path. Loyverse hands over the sale's details — product, price, customer, taxes, and payments — along with the cue to raise an invoice; AlphaPOS then forwards the finished invoice, an XML paired with a QR-coded PDF, to be validated. It covers more than one scenario. Per the listing, it works both for businesses issuing under their own numbering and for resellers handling several clients at once. It is set up a single time and then runs by itself. AlphaPOS configures the merchant's credentials and ties the integration to the Loyverse account; the listing also says the app is already running in active Panamanian businesses. Its compliance claim comes from the vendor. The listing presents the integration as fully compliant with the DGI's electronic invoicing rules — a statement made by the provider itself. One thing worth checking on your own: Panamanian rules require electronic invoices to be authorized through the SFEP, by way of either the DGI's free tool or a registered PAC. As of June 2026, AlphaPOS (Soluciones Técnicas Alpha S.A.) is not listed among the DGI's published Qualified Authorized Providers (PAC). Before leaning on any integration for compliance, merchants can cross-check the current roster of authorized providers on the DGI's own website. Getting going, according to the listing, means downloading the AlphaPOS Integrator app from Google Play (for now, Panama only) and reaching out to AlphaPOS to handle licensing, activation, installation, and setup. Common questions from merchants and developers Does a PDF count as a valid invoice in Panama? No. A regular PDF, or a scan of a paper bill, is not a valid electronic invoice. To carry fiscal weight, the document has to be structured XML, digitally signed, validated through the SFEP, and stamped with a unique code (CUFE). CUFE and CAFE — what is the difference? The CUFE is the unique identifier created at authorization that lets anyone verify an invoice with the DGI. The CAFE is the human-readable counterpart — usually a PDF with a QR code — that you print or send to the customer. Who is obliged to use a PAC in 2026? Any taxpayer invoicing more than B/. 36,000 a year, or issuing more than 100 invoices a month. Stay under both and the DGI's free tool is still open to you. For how long do electronic invoices need to be kept? Plan on holding the signed XML and the readable receipt for at least five years, consistent with normal audit and record-keeping expectations. Can sales continue if the system goes offline? Yes. The Panamanian framework permits contingency issuance, with the documents submitted for validation once connectivity returns. Does Loyverse produce Panama e-invoices on its own? No. Loyverse has no native Panamanian e-invoicing. For Panama, its App Marketplace lists a third-party AlphaPOS integration that captures Loyverse sales and forwards electronic invoices to the tax authority. The essentials at a glance Being compliant in Panama hinges on signed XML, pre-validation, a unique code, and sound archiving — emailing a PDF is not enough. The controlling instruments are Law 256 of 2021, Decree 766 of 2020, and Resolution 201-6299 of 2025. Since January 1, 2026, any taxpayer above B/. 36,000 a year or 100 invoices a month has to rely on a PAC or a DGI-certified system. Developers need to build valid XML, sign it, clear it through a PAC, and return both the CUFE and the CAFE. For Panama, Loyverse lists a third-party AlphaPOS integration that captures POS sales and forwards electronic invoices to the tax authority; since AlphaPOS itself is not on the DGI's published PAC list, confirm the certified provider standing behind any integration. -------------------------- Here's a glimpse of what the Loyverse API makes possible: a third-party developer shipped a single Marketplace app that channels Loyverse sales straight into Panama's national e-invoicing platform (SFEP) — turning a compliance burden into a solved problem for merchants across the country. One developer. One API. A whole country unlocked. Your integration could be the next one on this list. Dig into the docs → developer.loyverse.com Ready to publish on the Marketplace? → https://share.hsforms.com/1qkxqlh34QZWuk7OkTru9eg14psi

Hi Loyverse team, I've built VentaLens (https://ventalens.com) — a read-only sales-analytics add-on for Loyverse F&B merchants: menu profitability, anomaly detection (voids / big discounts / off-hour sales / cash gaps), multi-store dashboards, and a daily email briefing. It's registered as a developer app and the OAuth connect is live and tested: • App ID: q0317l9ceM0L0gp1elYX • Read-only scopes only: RECEIPTS, ITEMS, MERCHANT, STORES, EMPLOYEES, PAYMENT_TYPES • We never write to Loyverse data. What's the process to get it listed in the App Marketplace, and what assets/details do you need? Logo, description, and screenshots are ready to send. Thanks! Karthik — SKANDAN PTE. LTD.

Hello @Paolo80 Thank you for sharing your invaluable experience!

Hi all, I'm a hotel operator in Zanzibar who ended up building a Loyverse API integration after failing to find one that handled our specific hospitality use case. The main challenges I needed to solve: Matching Loyverse receipts to the correct guest folio in Zoho Books Splitting revenue by category (Food, Bar, Spa, Tours) into separate Zoho revenue accounts Handling room conflicts when two guests occupy the same room on the same day Distinguishing room charges from cash/card payments and posting accordingly The integration runs on Node.js, polls the Loyverse receipts endpoint every 15 minutes, and posts line items to open draft invoices in Zoho Books via their API. A few things I learned about the Loyverse API along the way: Customer codes are the most reliable way to match guests to room numbers The receipts endpoint doesn't return category names — you need a separate call to /items to resolve category IDs There's no native webhook support so polling is the only option for near-realtime sync Happy to discuss the technical implementation with anyone working on similar integrations. I've also packaged this as a SaaS product at loybooks.com if anyone wants to try it without building from scratch. Paolo Zanzibar, Tanzania

Hi Loyverse team, I want to bring back the request for creating orders via API. Right now, many restaurants use delivery apps like Wolt, Uber Eats, etc. Without this API, orders have to be entered manually into Loyverse, which slows things down and leads to mistakes. Receipt integration doesn’t really solve it because it bypasses key POS features like KDS and proper order flow. An order creation API would make it possible to: Integrate delivery platforms properly Use Loyverse POS + KDS as the main workflow Reduce manual work and errors in the kitchen If there are blockers, it might also be a reason some businesses consider switching to other POS systems that already support this. Is this something that could be reconsidered or added to the roadmap? Thanks!

What is PMS? Who is the user? What are the benefits? A Property Management System (PMS) serves as the central operational hub—often called the "nervous system"—of any hospitality business. It’s a comprehensive software platform thoughtfully designed to help manage the day-to-day operations of a hotel, resort, or short-term rental property with ease. Who benefits from using it? A PMS supports virtually every department within a hotel, helping ensure smooth and coordinated operations: Front Desk Agents: They rely on the PMS for checking guests in and out, managing room keys, and handling guest profiles efficiently. General Managers: Use it to keep an eye on daily performance, occupancy rates, and overall revenue, helping them make informed decisions. Housekeeping Staff: Benefit from real-time tracking of room status (clean, dirty, out of order) and can manage daily cleaning schedules more effectively. Revenue Managers: Analyze booking trends, adjust room rates dynamically, and distribute inventory across online travel agencies (OTAs) to optimize revenue. How does it help your hotel? The main advantage of a PMS is automating many administrative tasks, which helps reduce human error and frees your staff to focus more on creating a wonderful guest experience. It centralizes billing, improves internal communication, and keeps booking data secure. The Development Relief: While a PMS excels at managing room inventory, hotels also need a Point of Sale (POS) system to handle their additional facilities like restaurants, bars, gyms, and gift shops. Historically, PMS providers tried to build their own POS modules to offer an "all-in-one" solution. However, creating a competitive POS requires ongoing, complex development to manage features like F&B inventory, table management, kitchen ticketing, and retail barcoding. By choosing a PMS-Freemium POS integration approach, PMS providers can relieve themselves of this heavy development load. Instead of stretching resources to build and maintain a secondary product, they can integrate seamlessly with a specialized, freemium POS through open APIs. This thoughtful strategy lets the PMS provider focus fully on their core lodging software while still offering hotels an easy way to route restaurant and shop charges directly to a guest's room folio. Statistics of value-added facilities (restaurants, gyms, shops) by hotel grade As a hotel moves up in star rating, it's completely understandable that managing value-added facilities becomes more important, and having a strong POS system to support this is essential. Here's a clear breakdown to help you see how facilities typically grow from lower to higher-grade accommodations: 1. Economy & Budget (1 to 2-Star Hotels) At this more modest end of the scale, the main focus is understandably on room revenue. Value-added facilities tend to be very limited or highly automated, which keeps things straightforward. Dining & Retail: Usually limited to vending machines or simple self-serve, complimentary breakfast bars. It's common for 1-star and 2-star properties to not have on-site, full-service dining options (RoomMaster, 2024). POS Needs: These are minimal here. Since charges are almost entirely for the room, the core PMS manages all billing smoothly without requiring a complex F&B POS system. 2. Midscale & Upper-Midscale (3-Star Hotels) This tier thoughtfully combines comfort with practical facilities, designed to meet the needs of both leisure and business travelers who appreciate having essential conveniences readily available during their stay. Dining & Fitness: We understand that many business travelers value convenience—according to a survey of those staying in midscale to upscale hotels, 47% prioritize having an on-site restaurant, cafe, or bar, and 27% appreciate access to a gym (BCD Travel, 2023). These amenities can significantly enhance your comfort and well-being while you're away from home. POS Needs: These hotels typically offer features like a casual dining restaurant, a small lobby bar, or a gift shop. An integrated freemium POS system can be especially helpful here, allowing you to enjoy these additional services smoothly without increasing the hotel's software expenses. 3. Upscale & Luxury (4 to 5-Star Hotels) For luxury properties, value-added facilities are more than just amenities; they play a vital role in enhancing your experience and significantly contribute to revenue. These properties offer multiple fine-dining restaurants, full-service luxury spas, expansive gyms, and high-end retail boutiques designed to delight and pamper you. The F&B Impact: Research by real estate and investment firm JLL shows that 60% of luxury travelers prioritize staying at hotels with excellent restaurants. These prestigious restaurants not only enhance your stay but also help high-end hotels achieve a 6.7 percentage-point higher occupancy rate compared to similar hotels without them (JLL, 2024). Revenue Contribution: It's important to note that food and beverage operations contribute a significant portion of profit—averaging 27.8% of gross hotel profit (JLL, 2024). POS Needs: For your convenience, a 5-star hotel relies on a highly advanced, multi-terminal POS system. This system expertly manages high-volume, complex orders across spas, poolside bars, and fine dining venues—all seamlessly syncing with your central PMS folio to ensure a smooth and personalized experience. Loyverse has several PMS integration partners Loyverse is one of the top freemium POS applications on iOS and Android, and it offers several PMS integration options to help you streamline your operations. Hotefy - Hotefy is a web-based PMS app that makes it easier for your guests to access hotel services through a convenient QR code. Cloudbeds - Cloudbeds is an all-in-one, cloud-based hospitality management platform designed to support independent hotels, hostels, vacation rentals, and B&Bs, helping you manage your property with ease. Room Charge - Room Charge acts as middleware connecting Loyverse with over 10 PMS services, including Cloudbeds and Opera, to simplify your integrations. The following image illustrates a general POS - PMS integration structure to give you a clearer understanding. By syncing a customer list and sales in a restaurant, hotels can comfortably benefit from the intuitive freemium POS, designed to make your work easier. Loyverse FREE features include helpful tools such as: KDS/kitchen printer to streamline your kitchen operations Variation of items to help you customize your menu with ease Ingredient management so you can keep track of your supplies effortlessly Dining option to accommodate your customers’ preferences …and more features designed to support your business smoothly.

Hello! This is our API documentation: https://developer.loyverse.com/docs/

Hi is there some kind of documentation how to create an extension to integrate with electronic invoice for an specific country

That is right. Unfortunately, receipts created via API can't have more than one payment type.

Hello! By default, the limit of the Loyverse API is set to 50. But it is possible to change the number of objects returned in the response. It can be done by passing the limit parameter. The default value is 50, and the maximum is 250. You can also try pagination. https://developer.loyverse.com/docs/#section/Pagination

Global e-invoicing is a huge, standardized ETL (Extract, Transform, Load) and API integration challenge. Viewing the 2024-2026 e-invoicing landscape as more than a tech upgrade reveals a major shift in business and government communication. From 2024 to 2026, e-invoicing shifts from a "nice-to-have" to a global mandate. The key driver is now fiscal transparency. Governments aim to close the "VAT Gap" by requiring real-time transaction reporting. 1. Trends in e-invoicing A. From post-audit to "clearance" models Traditionally, invoices were sent and reported weeks or months after transactions (post-audit). The main trend for 2024–2026 is shifting to Continuous Transaction Controls (CTC), requiring real or near real-time invoice data submission for continuous monitoring. Invoices are legally valid only after "clearance" via government platforms in real time, ensuring compliance before completion. This prevents "missing trader" fraud by giving tax authorities real-time visibility and matching data from buyers and suppliers for accuracy. B. The end of the "PDF" Standard PDFs sent by email no longer qualify as true "e-invoices" since they lack structured data needed for automation. The move away from PDFs supports more efficient, automated financial processes with less manual work. Trend: e-invoices now mean structured data in machine-readable formats like XML or JSON for automated processing. "Paperless" invoicing is outdated; the aim is "touchless" invoicing—fully automated from issue to payment without manual steps. C. Lowering of exemption thresholds E-invoicing mandates, once for large B2B firms, are expanding to include small and medium businesses (SMBs) by 2026. This broadens transparency and compliance across all business sizes. Revenue exemptions are lowered or removed, so even small merchants previously exempt must comply. D. Market growth The global e-invoicing market will grow as mandates spread across regions and industries. Growth is fueled by digital adoption, regulations, automation benefits, and fraud reduction. Market valued at about USD 15.9 billion in 2024, forecast to reach USD 68.7 billion by 2033, growing at a CAGR of 16.8% 2. What this means for SMB merchants For small merchants, this change may seem like a compliance task but brings key operational benefits. Here’s the selected table converted into HTML: Benefit Description Faster Cash Flow (DSO Reduction) Structured e-invoicing removes the "black hole" of emailed PDFs. Machine-readable invoice data allows instant approval by buyer's accounting software, reducing Days Sales Outstanding (DSO) so SMBs get paid faster. Cost Reduction Manual paper or PDF invoice processing costs more due to printing, postage, and errors. Automating saves money and time. Access to Supply Chain Finance Real-time invoice validation creates trusted data. Banks use this to offer faster, safer financing to SMBs, improving working capital. Future-Proofing As major buyers adopt standards, they’ll reject non-standard invoices. E-invoicing keeps SMBs "trade-ready." 3. How it works This section explains the technical setup behind modern e-invoicing. The "Structured Data" Standard Unlike PDFs, true e-invoices are text files in code formats like XML or JSON. UBL (Universal Business Language): A global standard. Semantic Mapping: Ensures "Total Amount" matches exactly between sender and receiver systems, regardless of software. The Four-Corner Model (Peppol Network) The common 2024-2026 framework, the Four-Corner Model, works like sending an SMS between different carriers. Corner 1 (Supplier): Sends invoice to their Access Point. Corner 2 (Sender’s Access Point): Converts data to a standard format and sends it securely. Corner 3 (Receiver’s Access Point): Receives, validates, and converts data for buyer's software. Corner 4 (Buyer): Gets clean data directly into their ERP or accounting system. This lets an SMB using "Software A" bill a client using "Software B" without custom links. API-First Connectivity Modern e-invoicing uses RESTful APIs for communication. Instead of manual entry on portals, accounting software uses APIs to send invoices directly to tax servers. Security: Encryption and digital signatures protect data during transit. 4. Real case Loyverse works with middleware like Myinvoice2u and Jomeinvoice to help SMBs meet Malaysian LHDN e-invoicing rules. They built the integration using the Loyverse API, providing a strong platform to connect services and support Malaysian merchants efficiently.

So there is no way to push a sale receipt with multiple payment types to loyverse API? So you cannot push a split payment type?

We have identified an issue with the Loyverse Get a list of items API (https://api.loyverse.com/v1.0/items). The API consistently returns a 403 Forbidden error when the request includes more than 50 IDs in the item_ids parameter. However, the request works as expected when we reduce the number of IDs to 50 or fewer. It appears there might be a limit on the number of IDs allowed per request, or the request size is triggering a security block, even though our credentials are valid. Endpoint: GET https://api.loyverse.com/v1.0/items Trigger: Sending > 50 item_ids Result: 403 Forbidden Error loyverse_error.txt

Thank you for reporting!

Hello. Thank you for your question. Unfortunately, it is not possible to post receipt by using get request. Best regards,

I have try a lot of different way to get data from Receipts by Item with google sheet script every column of my data went fine expect "Categoty Name" and "Modifier Applied (Option Name)" here is my sample code that's function function getLoyverseData_Fixed() { const ss = SpreadsheetApp.getActiveSpreadsheet(); let sheet = ss.getSheetByName(SHEET_NAME) || ss.insertSheet(SHEET_NAME); sheet.clear(); const headers = [ "Date", "Receipt #", "Item Name", "Category Name", "Modifier Applied (Option Name)", "Modifier ID", "Status" ]; sheet.appendRow(headers); const categoriesMap = fetchCategoriesMap(); const todayStart = new Date(); todayStart.setHours(0, 0, 0, 0); const url = `https://api.loyverse.com/v1.0/receipts?created_at_min=${todayStart.toISOString()}&limit=250`; const options = { 'headers': { 'Authorization': 'Bearer ' + LOYVERSE_TOKEN }, 'muteHttpExceptions': true }; const response = UrlFetchApp.fetch(url, options); const json = JSON.parse(response.getContentText()); if (!json.receipts) { Logger.log("Failed"); return; } let rows = []; json.receipts.forEach(r => { r.line_items.forEach(item => { let catName = item.category_name || categoriesMap[item.category_id] || "No Category"; let modOptions = []; let modIds = []; if (item.modifiers) { item.modifiers.forEach(m => { modOptions.push(m.option_name || m.name); // ดึง Option Name ตามภาพ modIds.push(m.modifier_id); }); } rows.push([ r.created_at, r.receipt_number, item.item_name, catName, modOptions.join(", ") || "-", // คอลัมน์ U modIds.join(", ") || "-", // คอลัมน์ V r.receipt_type ]); }); }); if (rows.length > 0) { sheet.getRange(2, 1, rows.length, headers.length).setValues(rows); sheet.autoResizeColumns(1, headers.length); Logger.log("Done checking at" + SHEET_NAME); } } function fetchCategoriesMap() { let catMap = {}; try { const res = UrlFetchApp.fetch('https://api.loyverse.com/v1.0/categories?limit=250', { 'headers': { 'Authorization': 'Bearer ' + LOYVERSE_TOKEN } }); const json = JSON.parse(res.getContentText()); if (json.categories) { json.categories.forEach(c => { catMap[c.id] = c.name; }); } } catch(e) { Logger.log("Failed"); } return catMap; } result is Category and Modifiers return blank and I can't use this data to run around powerBI with sheet sources to visualize for my team. By far I'm not sure if I call a wrong data name or I just can't get these both data. I'm not really developer just a marketing so if anyone can help me fixed this please.

In your API reference, you have put this... The receipt object payments > The list of payments. There is a restriction that only one payment can be applied to receipt when using POST request. Does that mean a receipt can be sent with a GET request, and multiple payment IDs can be sent - to allow for a split payment?

Yes - I assumed that. But it looks like now that the urls are being returned - so either you fixed something, or there was a reason it was not returning. Either way - it looks like it's working now. Thank you

would you like to send the zip to test it?