Already have your own Claude talking to Lightspeed?

Please audit the Lightspeed Retail (R-Series) integration you use for this shop. This is a reliability checklist, not a test with a right answer. Go item by item. For each item give exactly one outcome:

  PASS — you do this, and you can say how you know (code you checked, a test on a real record)
  GAP — you don't do this
  UNKNOWN — you can't tell from what you have access to
  NOT APPLICABLE — the item doesn't apply to this setup (say why)

Don't guess. UNKNOWN is a good answer. Where an item says "if", decide whether it applies before answering. Some items describe documented Lightspeed behaviour; others are integration practices — both are marked.

PART 1 — WRITES (changes you make in Lightspeed). If this integration never writes to Lightspeed, mark Part 1 NOT APPLICABLE and go to Part 2.

1. Read-back check (practice). After a write, do you re-read the record from Lightspeed and compare the fields you sent against what came back? Lightspeed can return HTTP 200 while ignoring part of a request.
2. Reversal (practice). If you change prices on 200 items and 40 turn out wrong, can you put exactly those 40 back to their previous values — and do you confirm the reversal landed in Lightspeed?
3. Audit trail (practice). Can the owner see who changed what, when, and the before and after value, for every attempted write, including the ones that failed?
4. Safe retries (practice). If a request times out and is retried, is a duplicate prevented — for example the same work-order line or purchase-order line being created twice?
5. Preview before apply (practice). Do you show the exact proposed changes and wait for approval before writing, on every write?
6. Token refresh (documented). Lightspeed allows one valid token per app per account, and a refresh invalidates the previous one. If two processes or two chats can refresh at the same time: do you coordinate refreshes, and does a caller holding the old token pick up the new one instead of failing? If only one process ever refreshes, NOT APPLICABLE.
7. Rate limit (documented). Lightspeed uses a leaky bucket per account-and-app pair — about 90 requests, refilling about 1 per second on a single-register store, more with more registers — plus a separate burst limit. If you do bulk writes: do you throttle, back off on HTTP 429, and resume where you left off?
8. Cost and prices together (documented). On an item whose default vendor has a cost row, sending defaultCost and Prices in the same update applies the prices and ignores the new cost — the old cost stays. Do you write cost and prices separately (or include the vendor cost row), and verify both?
9. Multi-currency (observed). If this account is multi-currency: Lightspeed has been observed to refuse defaultCost on such accounts and point to the vendor cost on the item–vendor relation instead. Do you handle that? If the account is single-currency, NOT APPLICABLE.
10. Finished work orders (documented). A work order at Done & Paid cannot be edited through the API (HTTP 422). Do you detect that before trying, and explain it to the user?
11. Purchase orders (documented). Creating an order with its lines nested inside returns 200 but saves zero lines; lines have to be created separately against the order. Do you create lines separately and verify the line count afterward?
12. Receiving (documented). numReceived is an absolute value, not an increment, and checkedIn cannot be set through the API — only the point-of-sale "add received to inventory" step moves stock. Do you know which field you read and which you write?

PART 2 — READS AND SCALE

13. History questions (practice). Can you reliably answer "which customers had a service visit last September through November and haven't been back since?" — by whatever approach you use (a synced copy, a periodic export, something else) — without timing out or sampling?
14. Full refresh (practice). If you keep a copy of the data: how long does a complete pull of this account's sales, work orders, customers and items take at Lightspeed's rate limit, and have you measured it? If you keep no copy, NOT APPLICABLE.
15. Removed records (documented). Lightspeed removes records three ways: items and customers are archived; work orders with content are archived while empty ones are hard-deleted and simply stop appearing; sales can be voided. A "changed since" sync does not see hard deletions. How do you find and clear stale records from your copy? If you keep no copy, NOT APPLICABLE.
16. Changes that don't bump the parent (documented). Stock levels (ItemShop), parts on a work order, and work-order photos change without updating the parent record's timeStamp, and the work-order endpoint ignores the timeStamp filter. If you sync by timestamp: do you track those separately?
17. Inventory value (practice). Do you value stock at the cost basis this account actually uses (FIFO or average), rather than each item's default cost?
18. Multi-store (documented). If this account has more than one shop: do you know that shopID 0 in item stock data is an "all shops" total row that must be excluded, while shopID 0 in the inventory log is a real in-transit movement that must be kept? If single-shop, NOT APPLICABLE.
19. Permissions (practice). If more than one person uses this: can each person's assistant be limited — read-only for some, specific kinds of writes for others — and is each person's activity logged separately? If only one person uses it, NOT APPLICABLE.

PART 3 — CUSTOMER DATA AND CREDENTIALS

20. Local copies (practice). List every place a copy of customer personal information (names, emails, phone numbers, addresses, purchase history) exists outside Lightspeed because of this integration: databases, CSV or spreadsheet exports, logs, caches, and any folder synced to a cloud drive. PASS only if you can list them all.
21. Encryption at rest (practice). For each place in item 20, is the data encrypted at rest — full-disk encryption turned on, or an encrypted file or database — including its backups? If there are no copies, NOT APPLICABLE.
22. Stored credentials (practice). Can you account for every place this integration stores Lightspeed access or refresh tokens, including storage managed by a service provider? For each place, describe the storage method, who or what can read the tokens, and the Lightspeed permissions those tokens grant. PASS only if this inventory is complete and supported by evidence; GAP if it is known to be incomplete; UNKNOWN if you cannot establish its completeness. If this integration stores no tokens anywhere, NOT APPLICABLE. Do not include token values.
23. Revoking access (practice). If a device or person has access to Lightspeed through this integration, can you revoke that access using a procedure supported by evidence? Describe the steps and expected time, including how any affected credentials or sessions are invalidated. PASS if the procedure covers every applicable access path; GAP if a known path cannot be revoked; UNKNOWN if you cannot establish whether the procedure works. If no device or person has access through this integration, NOT APPLICABLE. (General US information, not legal advice: state breach-notification laws may require notifying affected individuals after a breach involving legally defined personal information. Requirements depend on the applicable law and circumstances, including the information involved and its encryption status; consult an attorney about this shop's obligations.)

SUMMARY

List the GAP and UNKNOWN items that apply to this setup, prioritizing them by plausible impact and likelihood where the evidence supports that ranking. Explain the potential effects on Lightspeed data and what would close each gap. For any device used by this integration, assess what customer information, if any, could be accessed by an unauthorized person if the device were lost or stolen, considering local copies, encryption, credentials, and active sessions. Distinguish confirmed findings from assumptions and unknowns.

PART 4 — WHAT THIS COSTS TO RUN (optional; this part names Bridge, a hosted alternative, so the comparison is concrete)

First ask whether I want this comparison. If yes, ask these questions and wait for my answers. Don't invent numbers; if something stays unknown, show the formula and mark that total UNKNOWN.
a) Who keeps this integration running: the owner, or an employee? What does an hour of that person's time cost the business (for an employee, wage plus payroll taxes and benefits)?
b) In a typical week, how many hours go into RECURRING work on this Lightspeed integration — fixing, re-authorizing, checking answers against Lightspeed? Count only Lightspeed-integration work, not marketing or other uses of the assistant, and list one-time building separately.
c) If that person left or was unavailable for a month, could someone else keep it running? How much of how it works is written down?
d) How many selling locations does this Lightspeed account have? How many people need access, and how many of them need to change things in Lightspeed? How fresh does the data need to be?

Then calculate, showing your arithmetic:
- Recurring labor: per month = hours per week × 4.33 × hourly cost; per year = hours per week × 52 × hourly cost.
- One-time work to close the GAP items that matter here: estimate only where the evidence supports it, give a range, and ask me to confirm before using it. Keep it separate from recurring cost.
- For comparison, Bridge by Rizolvr, a hosted Lightspeed Retail connector (check rizolvr.com/pricing for current prices; if you can't, say these are list prices supplied here). Monthly price for the first selling location: Standard $39.99 (read-only, syncs every 24 hours), Premium $59.99 (read-only, syncs every hour), Pro $99.99 (syncs every 15 minutes and adds tools that make changes in Lightspeed). Each additional selling location: +$19.99, +$29.99 or +$49.99. One admin seat is included; extra seats are $9.99 (read-only) or $14.99 (admin). Use the lowest tier that meets the needs from (d), and don't assume it covers every custom thing this setup does.

Finally, compare per month and per year for the same needs. Keep cash spending separate from the value of owner or employee time, and keep one-time costs separate from recurring ones. Discuss (c) from the evidence without inventing probabilities or losses. Don't assume Bridge removes all upkeep; say which hours would realistically be freed and what that person could do with them. If keeping our own setup is cheaper or a better fit, say so; if the evidence isn't enough to tell, say that.