Skip to main content

Overview

Welcome! The Mekari POS API lets your system work with a merchant's Mekari POS data: outlets, staff and shifts, customers and loyalty points, promotions and vouchers, the product catalog, inventory, and orders and returns.

Use it to connect Mekari POS with your own back-office system, online store, loyalty program or reporting tools.

Before You Start​

The merchant's Mekari POS plan must include the Public API add-on. The Plus and POS 360 packages include it; Essential does not. Without it, every request returns 403 with the code PLAN_FEATURE_REQUIRED. After the merchant adds the add-on, access starts as soon as Mekari POS receives the plan change, at the latest within one day. A few endpoints also need another plan feature, for example promotions or raw materials and recipes; see Errors.

Getting Started​

To integrate with the Mekari POS API, you need to complete 3 steps:

  1. Create an application — Register your application on the Mekari Developer portal to get client credentials (Client ID and Client Secret) and choose the scopes it may use. See Creating an Application for detailed instructions.

  2. Implement HMAC authentication — Every request needs an HMAC-SHA256 signature made with your Client Secret. See HMAC Authentication for the specification and examples in PHP, Node.js, Ruby, Java and Postman.

  3. Make API requests — Use the base URL https://api.mekari.com/v2/mekari-pos/v2 for production or https://sandbox-api.mekari.com/v2/mekari-pos/v2 for sandbox. Start with GET /outlets to see the merchant's outlets, then browse the API reference.

Key Concepts​

  • Outlet — Most endpoints work on one outlet of the merchant. Send the outlet id from GET /outlets in the X-Outlet-ID header. See Outlets and Acting User.
  • Acting user — Every write (POST, PUT, PATCH, DELETE) runs as one Mekari POS staff user. Send that user's id from GET /users in the X-User-ID header. The user's role must allow the action. X-User-ID is optional on POST /orders, not needed on PUT /order-source and the webhook endpoint calls, and optional on returns and refunds of your own partner order in one narrow case. See Outlets and Acting User.
  • Safe retries — Send an Idempotency-Key header on writes so that a retry never creates a second record. It is required on the POST calls that create a record, optional on PUT, PATCH and DELETE, and not used on quotes and approvals. See Idempotency.
  • Lists — Lists return up to 100 items per page and a next_cursor for the next page. See Pagination.
  • Webhooks — Get a signed notification when an order is paid, a kitchen ticket changes, a product or collection changes, or a product sells out. See Webhooks.