What do the APIs for the best point-of-sale platforms have in common?

Retailers who work with ShoppinPal are often surprised by its ease of setup. Within an hour or less, the retailer’s store is online and consumers can start shopping in-store via mobile devices. This is because we do the legwork of integrating with POS vendors ahead of time and when we show up at the retailer’s doorstep, all that remains is simple configuration to get them up & running.

In order to be judicious with our go-to-market strategy, we take time to rate various point-of-sale platforms in the market by (a) their adoption rate and (b) their developer API.

API Comparison

Starting from the bare-bones feature set and moving towards the fully-furnished ones, let’s have a sneak-peek at what the APIs for the best point-of-sale platforms have in common:

  1. Almost all the APIs have the foresight to expose an endpoint for working with products:
    1. GET /api/products – this will fetch all the products in a store’s POS, nice & easy.
    2. POST /api/products – add a new product to the store’s POS.
    3. The ones that stand apart, also provide a way to filter the result set by specific product fields such as UPC, SKU, barcode, product_handle, product_name etc.
      • GET /api/products
        • ?upc=1234
    4. A cut above, are the ones that provide paging and multi-field-filters too.
      • GET /api/products
        • ?filter=”name matches generic OR description matches generic”
        • &from=0
        • &size=50
  2. Next come the APIs that expose endpoints for invoices or sales:
    1. GET or POST /api/sales
    2. The ones that stand apart, also provide a way to iteratively update the fields on an existing sale, without resetting all the other fields back to empty or zero.
      • PUT /sales/<sale_id>/
        • application/json: { “notes” : “this is for my son’s birthday so make sure to wrap it nicely & put a bow on it”}
        • application/json: { “notes” : “paypal transaction number 111555”}
    3. Payments can be accepted and processed out-of-band. So the API should allow reporting transaction details, this way sales can be marked as paid and closed.
  3. The ability to provide notifications for any updates or additions to products, inventory, sales or customers – is another key feature of a platform that is geared for success. More and more this is done via webhooks as it doesn’t stress out the retailer or the POS’s infrastructure and still provides the highest level of flexibility to developers.
  4. Allowing an API endpoint which tells the timezone of a retailer can be important as well.
  5. And the holy grail of “engineering done right” is an API that exposes tax calculations:
    • GET /taxes/
      • request: customer is a US veteran, we are in a Venezuela duty-free airport area, its presidents day, and the purchase includes liquor, cigarettes, perfume, t-shirt, flip-flops and a Hugo Chávez poster!
      • response: after applying the various tax-free, tax-exempt, must-tax etc. rules, the POS should provide both the total and itemized taxes for a full breakdown.

Feel free to share your own experiences and grading structure based on the POS APIs that you’ve worked with … please use the comments section.

Image credit: Good APIs Project Blog

Leave a Reply

Your email address will not be published. Required fields are marked *