General questions
What type of license is more adequate for API calls? Can I consume an API with a logged user? What is the actual difference between a "regular" and an "API" user session? About request logs sent to SoftExpert, are they stored in it? What do I need to know about API error messages? Why am I receiving a Valid GatewayJWT not found in the request or user is blocked!
message?
What type of license is more adequate for API calls?​
License types vary according to what is needed. For example, if someone with a
STAFF
license is a web service user, they will not be able to create new users
through the adm_ws
service, since this is a feature that requires a more
permissive license.
Can I consume an API with a logged user?​
Yes, as long as the license allows it.
What is the actual difference between a "regular" and an "API" user session?​
The main difference between a "regular" and an "API" user session lies on the
way both consume licenses and manage their sessions. In both cases, a license is
consumed. However, when a web service is called, it does not register your
session in the session table. This means that access through /apigateway
does
not conflict with other web service or API calls for the same user, since none
of them will register an active session.
However, a scenario to be considered is when there is only one license for simultaneous users and there already is a user logged in to SoftExpert Suite – viewing a portal, for example. In this situation, web service calls will return an error 403. This happens because there is a user already consuming the only session actually available.
Therefore, while the "regular" and "API" user sessions may look similar at first, they have different characteristics as to license and session management, which must be taken into account in the design and implementation of solutions that use these resources.
Considering these scenarios, what is suggested?
- Register a specific user for API and SOAP web service consumption.
- Leave only one license available for this user. This is necessary because, in the case of external calls (whose license is not provided), SoftExpert Suite will use the first license it finds.
- Use a permissive license, according to your needs (if you wish to start workflows via web service, the license type must support this feature).
About request logs sent to SoftExpert, are they stored in it?​
Request logs sent to SoftExpert Suite are stored in the system itself. They can be accessed through the widgets available in the elements of the SoftExpert Administration component, which can be used during the creation of a portal. Alternatively, these logs can also be viewed through the import of a customized system portal.
This way, both the administrators and the users will be able to monitor and analyze requests sent to SoftExpert Suite, which makes it easier to track activities and solve potential problems.
What do I need to know about API error messages?​
Unless stated otherwise, most SoftExpert Suite endpoints returns a 200 OK
response to indicate a successful operation. If an API or web service returns a
different status code, specific information about the response will be detailed
in its own documentation.
SoftExpert Suite also has several standard error responses that different APIs share:
401 Unauthorized
: Response returned when the provided authentication is invalid. For details on how to correctly authenticate API requests, refer to our authentication and security section.403 Forbidden
: Code returned when the provided authentication does not contain the required permissions to access the specific URL.429 Too Many Requests
: Response returned when your account or application exceeds the API rate limits. We offer suggestions on how to operate within those limits in our documentation.
Why am I receiving a Valid GatewayJWT not found in the request or user is blocked!
message?​
This message is usually displayed when an error 401 occurs. In most cases, this
means that the API key
required for authenticating the request has not been
added to its header. Making sure that the Key API
is correctly incorporated
into the header of all requests you send is imperative for this error to be
prevented.
Alternatively, this message may also appear if the user used for the integration is blocked. If that is the case, check the status of the user and take the necessary measures to unblock them.
If you continue to receive this message after performing these two verifications, we suggest you contact the technical support for further assistance.