Models documentation.
Mustache is a generic template language that can be used to output all sorts of data, like for instance JSON or HTML. Here is a link to the official Mustache template documentation https://mustache.github.io. The handlebars export is similar to mustache, but is a bit more flexible. The documentation can be found here: http://handlebarsjs.com.
The CSV export is quite elaborate and can be configured to provide a huge variety of content. Line items can be aggregated together and grouped by things like VAT. Payment transactions can be grouped together by type and currency.
The Simple JSON transform lets you describe a simple, flat JSON output structure.
Configure this in order to send the transformed data as an attachment to a number of email recipients.
The web hook integration is a simple and easy way for you to obtain real time updates of sales from the Ka-ching system without the need to build your own integration framework. Each sale can be transformed or left as is and be POST
’ed to a URL. This would most likely require some kind of credentials or token to be added as part of the URL or set as an auth header when the POST
is performed.
We've built a retry mechanism that kicks in under certain circumstances to avoid manual handling of failed exports that have a chance to succeed if tried again a bit later. We will attempt an export up 5 times total (including the initial attempt) if:
All exported elements will be wrapped in a JSON dictionary. If you're using a cron export there will potentially be more than 1 element in the dictionary, but if you're using realtime export you're guaranteed to only have 1 element in the dictionary.
{
"<element-key>": {
...
},
"<element-key-2>": {
...
}
}
You can configure an export integration that will receive all checkouts
from an entire account
in the Ka-ching system. The Checkout
entity is described in details in the Models document.
You can configure an export integration that will receive all sales
from an entire account
in the Ka-ching system. The Sales
entity is described in details in the Models document and includes information about the line items in the sale, the payment transactions used to pay for the sale, the applied discounts and taxes, information about the source of the sale and the time of the sale.
You can configure an export integration that will receive all register close statements
from an entire account
in the Ka-ching system. The Register close statements
entity is described in details in the Models document and includes information about aggregated totals for sales, returns and grouped by product group. It also contains information about the reconciliations of payment types and information about the source of the register close statement and the time of the register close event.
You can configure the system to perform an export of product details every time they change in the system. This is useful for the situation where you use the Ka-ching system as the primary source for products and wish other systems to reflect any changes made to the products. Product creation, product changes and product deletion events are exported.
It's possible to configure Ka-ching POS or SecondScreen apps to enable a very basic newsletter signup form asking for email address. This information can be sent to systems like Mailchimp using an export-configuration transforming the newsletter signup-event to the format required to sign up in Mailchimp.
It's possible to get all stock events in the system through exports. The exported element looks like this:
{
"<element-key>": {
"adjustment" : <number, optional, either adjusment or new_stock_value must be present>,
"new_stock_value": <number, optional, either adjusment or new_stock_value must be present>,
"product_id" : "<string, required>",
"variant_id" : "<string, optional, present if it's a variant product>",
"sale_id" : "<string, optional, present if stock change is due to a sale>",
"stock_location_id" : "<string, required>",
"stock_count_diff": <number, optional, present if event comes from a stock count>,
"stock_count_expected": <number, optional, present if event comes from a stock count>,
"stock_count_id": "<string, optional, present if event comes from a stock count>",
"timestamp" : "<string, ISO 8601 format, required>",
"type" : "<string, required, can be return, sale, received, stock_count_reset or external_reset>"
}
}
The stock event export can be filtered to ignore certain types of events.
When an incoming order changes state in Ka-ching it's possible to receive notification of this event. The exported element looks like this:
{
"order": <order, required>,
"state": <order state, required>
}
Definition of the order object kan be found on our Models page.
Here's the definition of order state:
{
"created" : <number, epoch timestamp in seconds>,
"last_change" : <number, epoch timestamp in seconds>,
"last_change_by" : <cashier, optional>,
"last_change_comment" : "<string, optional>",
"order_state" : "<string, required, can be either created, processing, ready, completed, rejected, cancelled>"
}
The cashier object is defined as follows:
{
"display_name" : "<string, usually initials, required>",
"full_name" : "<string, optional>",
"identifier" : "<string, required>",
"image_url" : "<string, https url to image of store associate, optional>"
}
When an order is created in Ka-ching POS, and it is not being sent internally in the system to another shop, then it is exported as an 'outgoing order'.
Previously e-commerce orders were only indirectly sent through a sale entity, and the receiver would have to do some filtering to find the e-commerce line items. Now an order entity is created instead - and the intergrating system can send 'outgoing order state changes' back into Ka-ching in order to keep the system in sync with what happens to the order.
Definition of the order object kan be found on our Models page.