Your master IPS Connect application will be required to accept API calls from slave IPS Connect applications and respond to them accordingly, and to then propagate changes from those calls to any other slaves in the network. You must supply a unique key for your master application (which can be anything you want but must be unique to this installation) and the URL to the gateway API file that you will create to all slave applications. The master application secret key should be kept private and never be made public.
You must create a gateway file that slave applications will call to. These applications will send requests to your gateway file and will expect a response in JSON format to those requests (except for certain requests which result in redirection as outlined later in this document). Your master application will need to implement the API requests outlined below, accepting the expected GET parameters and responding with the outlined Response status code and parameters. Finally, the master application will also need to propagate the requests to all slave applications in its network (and thus needs to maintain a database of all slave applications that have connected with it).
The IPS Community Suite when acting as a master IPS connect application implements a queue system for requests to slave applications. If a request that should be propagated to a slave fails, it is inserted into a queue and reattempted at a later time. Any repeated failures are reported to the administrator via an ACP dashboard plugin. The requests will be automatically reattempted, or you can manually reattempt the requests from the dashboard.
While this system is not necessary in a master application, it can help to ensure data consistency across an IPS Connect network. If the master application ignores failures to a slave application, then email changes, name changes, password changes and more may not be propagated if a temporary error occurs.
Note that as the IPS Connect API is a public API, while the master key is required to communicate with it, you may wish to implement brute force protection against multiple subsequent login requests. This can help protect against brute force attempts made against slave applications that do not natively support such protection.
If a slave application no longer wishes to communicate with a master application, it should respond with a status of DISABLED when a request is propagated to it. If this happens, the master application should disassociate the slave application and cease sending further requests to it.
Report Document