Table of Contents
About Burti API
What is a REST API?
Simply put, an API is set of rules developed to expose data and functionality across the internet in a consistent format. Representation State Transfer (REST) is a term used to refer to API generally being accessed via HTTP protocol.
Resources often have one or more methods that can be performed on them over HTTP, most popular of them being, GET, POST, PUT and DELETE.
Burti REST API resources provides information or content, which can be accessed at a predefined set of URL and returns JSON-encoded responses, and uses standard HTTP response codes, authentication, and verbs.
Burti API is a simple implementation of a REST API. It is used for communication with Web stores, Logistics applications, Service applications, custom Web applications as well as Mobile apps.
Advantages of using a REST API?
Flexibility
A RESTful API breaks down a transaction to create a series of small modules. Each module addresses a particular underlying part of the transaction. This modularity provides developers with a lot of flexibility.
Suited for Web
REST technology is generally preferred to the more robust Simple Object Access Protocol (SOAP) technology because REST leverages less bandwidth, making it more suitable for internet usage.
Prerequisites to using Burti API
Hansa Application Language license
To make use of the Burti REST API a HAL license is required. The license might come included in your product's base package, depending on your country and the product you are using, but typically this will not be the case (e.g. with Standard ERP).
Hansa Application Language knowledge optional
To take advantage of the more advanced aspects of the API, you will benefit greatly from having some HAL programming knowledge or a HAL programmer's assistance. For simpler use cases this might not be necessary.
In this documentation topics and API elements and functions that either require or can be altered by HAL programming will be marked with a lightbulb 
symbol.
Burti API license and package
Burti API is not included in Standard ERP base package. You will need to acquire a license from us and as soon as the formalities are settled, you will be provided with the API module package (see panel to the right for explanation of the contents of the package which includes an enabler key file).
You will need to place these files on your Standard ERP server.
You likely do not need to read this section in detail, since typically we will install these files for you. If this is indeed the case, please, feel free to skip ahead to the next section.
| File | Description |
|---|---|
Burti Enabler - Enables Burti package functionality | |
| If you are already using any Burti functionality packages, you will likely already have this installed. |
halcust/datadefEN.hal | Support file. You must amend your Exec_file("halcust/datadefEN.hal");
|
halcust/enab/... files | These files need to be added to your HAL Rules setting and distributed to client computers. These will add UI elements that will allow you to renew Burti Enabler keys from your SERP client if necessary. |
Burti API package | |
hobcust/JSON.hob | |
halcust/datadefJSON.hal | Support file. You must amend your Exec_file("halcust/datadefJSON.hal");
|
halcust/json/... files | These files need to be added to your HAL Rules setting and distributed to client computers. These will add UI elements that will allow you to configure the Burti API functionality. |
| These will most likely be empty folders at first but will be populated by support files generated by the package. These will provide the main functionality of the API. |
Enabler key file | |
BurtiEnabler.bkey | This file contains the product key that enables the use of the package. This will need to be updated periodically with a new key. However, this is done automatically in most cases and you will likely not need to bother with this. The contents of this file can also be manipulated via the Burti Enabler package mentioned at the top of this table. |
Configuring Burti API
Security
There are several layers of security that can and should be implemented to protect your data and your API transactions from snooping from unwanted parties. As a minimum we recommend configuring and using HTTPS in tandem with an authorisation token. This will ensure that the data you send and receive over the API is virtually impossible to access by unauthorised third parties.
HTTPS (HTTP over SSL or HTTP Secure)
Burti API can be accessed both via HTTP and HTTPS, but it is strongly encouraged to serve your data over HTTPS only (this means disabling HTTP altogether).
This will ensure that your traffic is encrypted and safe from third party snooping.
See sample configuration to the right. The Program Mode setting is available in the Technics module (listed as a register).
Please note that this can be set up in multiple ways and very much depends on how your Standard ERP instance is run and where it is hosted. It very well may be that changes made to this setting will be overridden by command-line parameters or by settings in your hosting provider's Cloud control interface. If this is the case, contact your system administrator or hosting provider.
Firewall white-listing
Normally the parties accessing API's reside at fixed network addresses. This is not always the case, but does apply for scenarios like web stores, connections with logistics companies, reporting tools and many others. If you are providing access to software or tools that does reside at a fixed IP address or addresses, consider only allowing access to your server from these addresses in your firewall if you have one in place, or setting one up if you do not already. This way other parties will not be able to connect to the API at all, unless you explicitly allow them by whitelisting in your firewall software or hardware.
Authorisation token
Burti API can and should be configured to require a secret token for all transactions. Consider this a password. Usage of the API without a token should be limited to testing environments only.
The setting for this can be found in the "Burti - JSON API" module.
Tokens sent over a HTTP connection can easily be intercepted and stolen (as well as all other data sent along with it).
Custom security via HAL
Burti API allows you to implement additional layers and logic to control who and how can access the API as a whole or separately for its' endpoints. As us for more details on how to do it, as this is an advanced topic and will require HAL programming.
This is done using the field "Custom boolean auth.function" on each relevant interface definition record, found in the "Burti - JSON API" module.
The function can be as simple as a username/password check that is passed along additionally with the request or as complex as calculating and validating against a passed hash of the request by a pre-determined algorithm.
Interface generation
Retrieving the database structure of a register
To generate the various end-points Burti API relies on the database structure that Standard ERP exposes via the Export/import Format report in its' Technics module.
When the report is run without specifying a register code, it will dump the database definitions of all the registers in the database. These are for example Invoices, Sales Orders, Deliveries and such.
You will need to look up the register(-s) that you wish to expose via the API in this report and then separately export these to a text file.
Example
In this example we show how to retrieve the database structure of the Orders register to use for creating its' API end-point.
Step 1: Enter the keyword "Orders" in the search field of the report
Step 2: Cycling through the search results pin-point the correct register and take note of its' code (ORVc).
Step 3: Reopen to the Report Specification window using the cogwheel menu available in the upper-left hand corner of the window.
Step 4: Enter the register code (ORVc in this example) in the field labeled "Vc (View Code)", set Media to File and press Run to save the definition in a file.
Importing the register's database structure as an API Register Definition record
To start configuring the end-point, you need to create an API Register Definition record for it in the Burti - JSON API module. For this you can use a database structure definition file.
In Burti - JSON API module open Imports and select "Export/Import Format file" and pick the file.
In prior versions of the Burti API it was necessary to edit files exported in this manner to remove blocks that follow M4PackedMatrix fields up to and including double <CR> lines, but this is now automatically detected and ignored upon import.
Example
In the example we'll use the file created in the previous section to generate an API Register Definition record for the Orders register.
Navigate to Burti - JSON API module Imports, select "Export/Import Format file", pick your file and run the Import.
If all goes well, a new record should now be created in the API Register Definitions register for Orders (register code ORVc).
Congrats, you are now ready to start configuring!
API Register Definition - configuring your end-point
Records in this register are the facility for configuring the capabilities of your API end-points. You set what fields are accessible, how the records can be filtered, sorted, manipulated.
The 
lightbulb icon denotes parts of the Burti API that require or are related to HAL programming in some form.
| Field | Explanation |
|---|---|
| Vc code | This is the register code, this specifies which data the end-point is serving and updating. |
| ImportTag | This currently has no effect on anything |
MainKey | This is the name of the main key (primary key) for this register. You will need to know this, to configure the end-point properly. Most of the time you can guess this name by the "main" field in the register. For registers with numbered records this will typically be "SerNr", for records with a Code field it's typically "Code", but can sometimes also be called "MainKey" or something else. To be safe, you will need to consult with a HAL programmer, if you are not one yourself. |
| Import date and time | These are informative fields and show when the definition was imported. |
Support variable fields | These are used in more advanced use cases of the API. These support variables ar maintained throughout the lifecycle of each API request and are available in all HAL hook functions. You can store temporary data (e.g. implementing a cache of some data you do not wish to be re-read from the database for each record in a record set). You can specify multiple variables or even arrays or vectors of a variable type, depending on your need. |
| Block | Checked when the end-point is made for a block not register. |
| Export Attachments | When checked, information about attached files will be included in the JSON data for records accessed via this end-point. |
| View Attachments | When checked, an additional interface will be generated for attachment retrieval. |
| Add Attachments | When checked, an additional interface will be generated for adding attachments to records accessed via this end-point. |
| Delete Attachments | When checked, an additional interface will be generated for deleting attachments to records accessed via this end-point. |
| Do not use SequenceNumbers | No longer necessary, used in older versions of the API - the usage of SequenceNumbers for registers is detected automatically. |
| Field configuration | |
| Column | Explanation |
| Name, Type, Length, Location | These describe the field's parameters in the database structure. |
| In list | This determines whether the field is included when requesting the short/list version of the data. Typically used for retrieving record list with general data of the record (for displaying in record lists or other similar data overviews). |
| In full | This determines whether the field is included in the full set of record's data. |
| Filter by | Whether to enable filtering by this field when making API requests. |
| Index names (3 columns) | These all serve the same purpose - for listing comma-separated index names in which the field is included. This then enables proper sorting by these indexes. You do not need to list all indexes a field is used in, just the ones you actually wish to use. You also do not need to list an index on all of the index's fields, just the ones you actually wish to set your sort on or lookup records by. Same limitations apply as with using indexes in HAL - you can't omit a key field from the middle of an index. |
Generating API end-points
To generate the API end-point from your API Register Definition record, select the option(-s) you need under the cogwheel menu in the record.
To enable the Read API, select "Generate JSON read API"
To enable the Write API, select "Generate JSON write API"
After running these functions, you will receive a message box about generated HAL files for your end-point interfaces.
The structure and role of these files are as follows:
| File | Role |
|---|---|
halcust/serverJSON/generated-interfaces/JSON_InterfaceCallers.hal | This is is the main entry point for all API calls. Think of it as a router. Everything will go through this file and get re-routed to the appropriate API sub-routines. You won't need to ever make changes to this file. This file will always be re-generated when changing the API configuration. |
The register code for Orders - | |
halcust/serverJSON/generated-interfaces/JSON_ORVc.hal | This is the main Read API functionality. It contains code for all the indexing, filtering and include/exclude options you selected. You won't need to ever make changes to this file. This file will always be re-generated when changing the API configuration. |
halcust/serverJSON/generated-interfaces/JSON_ORVc_Tools.hal | This file is where the Read API customisation happens. This contains all the available HAL hooks that you can take advantage of to either include additional data or add custom filtering or other behavior to the API. The various possibilities are documented towards the end of the documentation. |
halcust/serverJSON/generated-interfaces/JSON_Save_ORVc.hal | This is the main Write API functionality. It's responsible for populating the record with the field values that you pass via the API. You won't need to ever make changes to this file. This file will always be re-generated when changing the API configuration. |
halcust/serverJSON/generated-interfaces/JSON_Save_ORVc_Tools.hal | This file is where the Write API customisation happens. This contains all the available HAL hooks that you can take advantage of to either include record validations, additional calculations, changes to other linked records etc. The various possibilities are documented towards the end of the documentation. |
Read API
The Read API is accessed via the following URL:
https://your.server.address/Web_JSON_Composer.hal