Kounta by Lightspeed uses an OAuth 2.0 compliant RESTful API for easy integration with third-party applications.
Kounta by Lightspeed’s REST API is based at
https://api.kounta.com/v1/. There is no unencrypted (non-SSL) version available.
Add-ons are created and managed from within Kounta by Lightspeed. There you will find your
Client ID and
Client Secret for authenticating with the API.
To find out more information about creating your Kounta by Lightspeed add-on, see this knowledge base article.
Two types of authentication are available:
For more details, see the section on Authentication.
Requests and responses will use JSON.
When sending data via
as the format of the data you’re sending in the
Content-Type header of your request.
Any other value will result in a
400 Bad Request response status.
The format of the response body is determined by the file extension of the requested
endpoint, which is
you can omit the file extension if you include the aforementioned format in your
Accept header. If you omit the
Accept header and the file
extension, you’ll get a
406 Not Acceptable response status.
Data in Kounta by Lightspeed is represented in these formats:
Understanding data types isn’t critical, but it can help you avoid problems like
inadvertently trimming leading zeroes off phone numbers and rendering
as a string.
In some cases an
id field with a number type may represent a 64-bit integer, in which case we will also provide an
id_str string representation
of that number, as some programming languages may have difficulty interpreting 64-bit integers.
CRUD operations follow a few standard patterns. Deviations from these patterns are noted in the documents for individual actions.
GET requests result in
200 OK response
POST requests result in
201 Created response
Location headers containing the
GET URIs of
the newly created resources.
PUT requests result in
200 OK response
statuses, and include the updated record in the form of the corresponding
DELETE requests result in
204 No Content
/v1/customers ) often include abridged versions of
records, containing only descriptive information (e.g.
email) and an
id. In these cases, you can
GET the individual records by
id for more detailed
When you request a
of records (e.g.
to list all customers),
you’ll receive a maximum of
results. To retrieve the entire result
set, you’ll need to request additional pages.
Each page will include the
header that will contain the full URL to request the next set of 25
results. This process can be repeated until all the records have
Regarding the cursor provided by
X-Next-Page header is not present to retrieve all
resources from a paginated API.
GET requests will include
Etag headers. Subsequent
requests to the same endpoints should include this header’s value in an
If-None-Match header. If we send you a
304 Not Modified
response, you can save bandwidth and lighten our server load by using your cached
Read more about
Etag headers and HTTP caching here.
Kounta by Lightspeed will use standard HTTP status codes when your requests cannot be satisfied.
Additional error information will be sent in the response body as key-value pairs,
including an error code
error, an error description
error_description, and other diagnostically useful information.
Error responses are OAuth 2.0 compliant.
PUT requests are identically treated
as partial updates, i.e. only fields included in the request are altered. This
documentation will always specify
PUT, but you can use
PUT interchangeably if you like.
There are plenty of good plugins for both Firefox and Chrome for testing REST APIs.
If you prefer to use cURL or something a little less
sophisticated, try sending an
X-Pretty-Print: 1 header with your requests.
We'll format the output with nice indentation to make it easier to read.