Gateway Architecture

Before you start to explore the suite of APIs available in Gateway. It is important to understand a little about the architecture and how the Gateway software processes data.  Because Gateway is a micro service orientated architecture, there is a very strong division of ownership and responsibility between the service. One POST message may need to be consumed by several services, so all inbound POST messages are processed asynchronously. Since each service generally has a limited number of entities(objects) it has ownership of, Gateway has a concept of late-binding objects together, this facilitates keeping the services decoupled, but also removes any need for the ordering or sequencing of data injection.

The processing of POST messages asynchronously does pose a problem of the caller, in that, at the time of sending the message Gateway cannot give an immediate indication as to whether the data has been successfully injected into the platform. Gateway alleviates this by providing a Tracking API which allow the caller to query the platform as to the current state of any POSTed message.

The Gateway APIs are not open. Third parties wishing to use them must first register and be issue with a client’s identification code and secret. This will allow the caller to authenticate with the service to obtain a token that must be sent as a means of unique identification in every call made to the Gateway service. It is the Third party’s responsibility to make sure that the ClientID and secret are kept safe and secure.