# Improved Error Handling in CyberArk AAM Connector (Agentless Mode)

**URL:** <https://community.netwrix.com/t/improved-error-handling-in-cyberark-aam-connector-agentless-mode/123486>\
**Category:** Identity Manager Ideas\
**Tags:** under-review\
**Created:** [February 25, 2026, 10:03am UTC](https://community.netwrix.com/t/improved-error-handling-in-cyberark-aam-connector-agentless-mode/123486 "2026-02-25T10:03:22Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![raphael](https://avatars.discourse-cdn.com/v4/letter/r/edb3f5/32.png) [@raphael](https://community.netwrix.com/u/raphael)\
**Post date:** [February 25, 2026, 10:03am UTC](https://community.netwrix.com/t/improved-error-handling-in-cyberark-aam-connector-agentless-mode/123486/1 "2026-02-25T10:03:22Z")

</div>

### What is a one sentence summary of your feature request?

Enhance the CyberArk AAM connector to properly handle and expose non-JSON HTTP error responses (including status codes and raw messages) instead of masking them behind generic JSON parsing exceptions.

### Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.

Hello,

Following a recent analysis related to the use of the CyberArk AAM connector (agentless mode), an improvement opportunity has been identified regarding error handling.

🔎 Context

While retrieving credentials through the connector, the following error was reported:

Unexpected character encountered while parsing value: \<. Path ‘’, line 0, position 0.

After investigation, it appeared that:

- The remote API was returning a non-JSON response (most likely an HTML page generated by a proxy or intermediary component).
- The connector systematically attempts to deserialize the response as JSON.
- When the response is not in the expected format, only a generic parsing exception (JsonReaderException) is raised.
- The actual HTTP response content is not exposed in the logs.

This significantly complicates troubleshooting, especially in cases involving proxy configuration, firewall restrictions, network settings, or certificate issues.

⚠ Identified Issue

The connector currently:

- Does not explicitly handle HTTP responses that are not in the expected JSON format.
- Does not log the returned HTTP status code in error scenarios.
- Masks the root cause behind a JSON deserialization exception.

🎯 Enhancement Request

We propose enhancing the connector so that:

1. Non-JSON responses are detected before attempting deserialization.

2. The returned HTTP status code is systematically logged.

3. The raw response body (or a safe excerpt) is logged when an error occurs.

4. Error messages clearly distinguish between:

- JSON parsing errors,
- network errors,
- proxy-related errors,
- authentication failures,
- or functional errors returned by the remote provider.

✅ Expected Benefits

- Easier and faster troubleshooting of integration issues
- Better visibility into infrastructure-related errors
- Reduced support analysis time
- Improved robustness and observability of the connector

Thank you in advance for reviewing this enhancement request.

### How do you currently solve the challenges you have by not having this feature?

None.