Interpret an empty Axis API Discovery result before retrying an integration

Bottom line: Treat a successful empty discovery result as a capability finding to investigate, rather than a reason to repeat the same integration request indefinitely.

Source fact: documented behavior

Axis explains in API Discovery service that searching for an API unsupported by the device is not considered an error.

For that unsupported-API example, the response contains an empty apiList.

The getApiList operation can filter results by API identifier and version.

What the source does not establish

Do not turn an empty filtered list into a conclusion that the device has no public APIs. First verify the exact requested identifier and version. Keep this capability check separate from authentication, network reachability and the success of the business workflow. Require product-specific documentation before promising that another device or software release will expose the same interface.

Applicability questions

• Which exact API identifier and version does the integration require?
• Was the request filtered, and what identifier and version were supplied?
• Can the same authorized diagnostic session retrieve the unfiltered public API list?
• What supported alternative will the integration owner use if the required interface is absent?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends making unsupported capability a separate outcome in the integration’s commissioning record.

1. Start with a representative device in an authorized test environment. Record its model, software release and required integration function. Obtain the interface identifier from the relevant official topic rather than deriving it from the feature’s display name. Keep the request and sanitized response together so a later reviewer can see exactly what was asked.
2. Use a proposed comparison with three inputs: an unfiltered query, the precise required identifier and version, and a deliberately nonexistent identifier. Label the last input as a test fixture. Compare the response structure and returned entries without representing a fabricated API name as a real product capability. Separate a processed request with no matches from a request that reports a processing error.
3. When no required entry is returned, stop the dependent deployment step and ask the integration supplier to resolve its support requirements. Correct a mistaken filter before repeating the query; otherwise document the unsupported requirement and the chosen alternative. Do not silently substitute a different API version simply to make the test appear successful.

Verification and evidence

Retain the device identity, official interface reference, requested filters and complete sanitized response. Have a second reviewer match each required interface against the returned identifier and version, then record any unresolved dependency. Exclude credentials and sensitive addresses from shared evidence.

After a supported software or integration change, repeat the same saved query and compare the capability result before enabling the dependent function. Treat a newly returned entry as a reason to continue functional testing, rather than as acceptance of the complete application. These are proposed DSE checks; no device was tested for this article.

Official references

• API Discovery service — Axis Communications; official VAPIX documentation.

Source review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.