ERROR HANDLING

SLASCONE’s API uses standard HTTP status codes together with endpoint-specific business logic. A robust client integration should not only process successful responses, but also explicitly handle logical conflicts, transient platform errors, and no-connectivity scenarios.

The most important categories to handle are:

• 409 Conflict

• 429 Too Many Requests

• 50X server-side errors such as 502, 503, or 504

• no connectivity, where no HTTP response is returned at all

Regardless of your business case, your client should:

• catch and process 409 responses, because they are central to your business logic

• implement retry and fallback policies for 429 and 50X errors

• explicitly handle offline or no-connection situations

HANDLING 409 CONFLICTS

The documentation for each endpoint describes which 409 conflicts can occur. Your application should inspect and process these conflicts as part of normal business logic rather than treating them as technical failures.

For example, a 409 may indicate that:

• a license must first be activated

• a token is not assigned

• a floating limit has been exceeded

The exact set of possible 409 responses depends on the endpoint, as shown in the following screenshot taken from:

https://api365.slascone.com/swagger/index.html?urls.primaryName=V2#/Provisioning/AddHeartbeat

429 AND 50X ERRORS: RETRY AND FALLBACK

Although these errors are uncommon, they can occur under certain circumstances, such as server overloads or network issues. To handle such situations effectively, it is essential to implement the following:

• Retry Policy
  Use a moderate retry policy, with a recommended maximum of 1 retry. Avoid excessive retries to prevent further strain on the server. The API returns a Retry-After response header in case of 429/503/504 errors.

• Fallback Policy
  If retries are unsuccessful, implement a fallback policy. Whenever possible, prioritize graceful degradation over outright denial to avoid disrupting the end-user experience. For example, it may be preferable to provide partial functionality rather than none at all.

License Heartbeat (LicenseInfoDto)

POST /api/v2/isv/{isv_id}/provisioning/heartbeats

In many scenarios using this endpoint, especially desktop or single-tenant applications, the result of the latest successful heartbeat is stored locally. If a 50X error occurs, the recommended behavior is to fall back to the last locally stored result, similar to an offline scenario.

However, unlike a true offline scenario, the freeride period should not be applied in this case.

Get License by User (LicenseDto)

POST /api/v2/isv/{isv_id}/provisioning/licenses/by_user

This endpoint is intended for named-user scenarios that often involve multiple users, so local caching is typically not a practical fallback. If a 50X error occurs, retry once. If the problem persists, show a warning to the end user that the service is temporarily unavailable.

Open Session

POST /api/v2/isv/{isv_id}/provisioning/session/open

For this endpoint, the current recommendation is: if a 50X error occurs, treat the event as successful. In other words, continue as if a 200 OK had been returned.

This behavior should be implemented deliberately and in the context of your session strategy. As with all retry and fallback handling, evaluate whether your first open session and later refresh scenarios should behave identically. This endpoint is one example where endpoint-specific fallback behavior is especially important.

OFFLINE OR NO CONNECTION

Offline situations differ from HTTP error responses because no HTTP response may be available at all. In practice a no-connection scenario may surface either as:

• a low-level exception, for example DNS or socket-related
• or simply as a timeout, depending on the HTTP client, platform, and timeout settings

Whether your application should handle no-connectivity situations exactly like 429 or 50X errors depends on the endpoint and your use case. In many desktop scenarios, offline handling is based on previously stored valid state. In other scenarios, such as multi-user license lookups, that may not be feasible.

EXAMPLES

All of our GitHub examples handle 409, 429, and 50X errors as well as offline or no-connectivity situations. They can be used as reference implementations when designing your own retry and fallback strategy.