Some months ago, an article about potential problems connecting SecureTrack to a Check Point R80 Management Server has been published here. Most of the points are still true - except the option
   Menu > Settings > Monitoring > Check Point Management R80 > Test Connectivity
is now also testing the API connect to the Check Point Management Server (e.g. in R18-3).

As pointed out in Tufin Knowledge Center #10413, one reason for an API client error is the API itself. At the CLI of this machine an "expert" user can (and should) check the status of the api to be sure it's up and running. Tufin points out the resolution to allow access to the API from "All IP addresses", which is correct.

It might happen that access isn't possible even if the change has been configured, published via SmartConsole and the API has been restarted using CLI. Assuming that access to port 443/tcp is granted, another reason might be possible. In our lab this problem has been found using Check Point R80.20 with SecureTrack R18-3. It might happen in your environment also, but not necessarily.

Even if the change of allowed IP addresses has been published and the API has been restarted, it might not be active for the API. This can be checked by an "expert" user

[Expert@SMS]# api status
API Settings:
---------------------
Accessibility:                      Require ip 127.0.0.1
Automatic Start:                  Enabled

So in this case, the change hasn't become active and the API allows access from 127.0.0.1 only. This might also not change when the API is restarted again. In this case, try the command

[Expert@SMS]# api reconf
API reconfigured successfully

[Expert@SMS]# api status
API Settings:
---------------------
Accessibility:                      Require all granted
Automatic Start:                  Enabled

After the completion of the first command, the change is active and SecureTrack can access the API.