Retail API limitations and Questions
Our client recently moved to Lightspeed as their point of sale. We are in the process of developing their booking engine for the different services they offer. In working with your API, we learned about your drip rate. I spoke with Arianne before the holidays and she said that we could request an increase to the drip rate. It looks like we start at 1, but can request an increase to 3. This helps, but it seems like the limitation would still create queue when integrating with your POS api.
What options do they have in regards to the limitations of their api? Are there are other lightspeed solutions they should be looking at (They are not interested in 3rd party apps e.g. Booksy)
Below is an illustration of a basic service and a few comments :
Booking a 30 minute massage
1 lookup to see if a customer exists in Lightspeed.
1 Write to Lightspeed for create/update a customer.
1 Write to create a sale with line item 30 minute massage.
This is an example of the minimum information in a request. It’s assuming we don’t need to perform any additional lookups (pull the store, register or product codes because we have them stored on our end). It’s 21 points against our limit. So there’s a max of 2 simultaneous bookings we could ever handle with a count of 60. After that, we’ll need at least 21 total points to handle another booking. Assuming these totals for every booking, if we got a drip count of 3, we could in theory handle a max of 11 bookings a minute. That’s an absolute max and would only happen if someone booked at exactly the times we had enough points to book. So the practical minute to minute total would be fewer. With the current drip rate of 1, the highest possible bookings is 5 in a minute. Those numbers assume we start the minute with a full bucket. If we empty it, we could potentially get 8 bookings the following minute with a 3 drip rate and 2 bookings with the default 1 drip rate.
The 60 points is more of a general amount. It’s not always 60 points. Docs say it’s higher during off peek hours, but we’ve seen posts in the forums that the limit is actually lower during high traffic periods.
For Gift Cards and Discount
We also have discounts or gift cards work in this system. Gift cards appear to be based on physical cards, so I don’t know if it’s possible to just create one with their required characters. We couldn’t find a form in the light speed admin for gift cards for creating new ones. If we can, we’d need to expend a point on a lookup anytime they supplied us with a gift card. We’d need to do that before performing a transaction, then pass in the sale with the returned gift card id to have it remove the amount.
We’re going to have to actually try some of this to confirm it works, but I think the gift card management is possible. You can create a sale for a gift card and assign a code for it there (there’s a required format for gift cards). Through the api, gift cards involve creating a credit account attached to a customer account. If someone purchases a gift card from the site, there’s the normal stuff I’ve defined (account and sale call to api), and a third write to setup the credit account. So that’s at least 31 points of api calls. For someone to use the card, we’ll need to store the credit account’s id and the card code on our end so we can do a lookup to get the balance, then subtract it’s balance from the order, charge that amount with the payment gateway, then post the sale to Lightspeed with the credit account code of the gift card so Lightspeed will update its balance. So gift card usage will always involve an extra api point for the gift card lookup along with what’s normally used for the booking.
Also, I did find a way to define products with no inventory. I don’t know how that effects actual purchases since a sale record includes a price and a quantity (not sure if I can pass a quantity for a non-inventoried product). When you send a sale record, you pass a total but also the id and quantity of all the items purchased. Lightspeed uses the ids to lookup the prices of the products purchased to confirm they match the total you send. Since some activities can book multiple reservations in the same order, that’s analogous to purchasing multiples of a product while will need to line up in the api call. That hopefully works fine with non-inventory.
In terms of components, everything we need appears to have a means to work with Lightspeed (except actually charging their card; we’ll have to do that separately). The issue still will be the throttling and how much overhead and possible slowdown for booking that will cause and what we do if we run out of points to make calls when a booking happens. If we queue everything, we’ll have the limitations of updates to their system all happening on an unknown delay. It’ll limit gift card usage since we have to perform a real time lookup on gift cards in order to use them; we’ll have to wait until they’re written to Lightspeed before they can be used.
Let me know if all this makes sense.
Thanks for your assistance.