HTTP 406 Error in Custom Connector Due to Misinterpretation of HTTP 201 Response

1. Summary of the Issue

Hi! I am building custom connector for Apify API in Integration Service but when a custom connector executes a POST request to an asynchronous API endpoint that creates a new resource (e.g., starting a job), the connector fails during testing and execution. I testes this with “send request” in Integration Studio and in Studio. I am on Community tier with Cloud access.

  • Endpoint Called: POST /acts/{actorId}/runs (Apify’s asynchronous “start actor” endpoint).
  • Error Displayed in UiPath: Error: 406 Not Acceptable.
  • Accompanying Message: “Redirects are unsupported for custom connectors.”

This issue prevents integration with any standard RESTful API that follows the common pattern of returning a 201 Created status with a Location header for asynchronous resource creation.

2. Analysis of the HTTP Transaction

A step-by-step review of the transaction within the connector’s test utility reveals the precise point of failure.

Step 1: Successful Request and Provider Response The initial POST request from the UiPath connector to the Apify API is successful. The “Provider Response” tab confirms that Apify’s server receives the request and responds correctly, as per RESTful API best practices.

  • Status Code: Apify returns HTTP 201 Created, correctly indicating that the request was successful and a new resource (an actor run) has been created.
  • Response Headers: The response includes a Location header (see Image 1), which contains the URL of the newly created resource. This is a standard way to inform the client where to find the resource it just created.
  • Response Body: A valid JSON payload is returned (see Image 2), containing metadata about the newly initiated run, including its unique ID.

Image 2: Provider Response Body Showing Successful Run Initiation (This image shows the valid JSON body from Apify, confirming the API call was successful and the actor run was started.)

Up to this point, the communication between UiPath and the external API is flawless.

Step 2: Internal Failure within the UiPath Connector Framework The failure occurs after the connector receives the valid 201 Created response. The UiPath framework appears to automatically attempt to perform a subsequent GETrequest to the URL provided in the Location header.

However, the framework itself has a limitation where this “follow” action is not supported, leading it to generate the error: “Redirects are unsupported for custom connectors.”

This is a misinterpretation. An HTTP 201 Created with a Location header is not a redirect (3xx status code). It is a pointer to a new resource. The connector framework is failing to handle this standard, non-redirect response pattern.

3. The Misleading 406 Not Acceptable Error

The final 406 Not Acceptable error code is symptomatic, not diagnostic. A true 406 error indicates a content negotiation failure, where the server cannot provide a response in a format specified by the client’s Accept headers.

This is demonstrably false in this case:

  • The client requests application/json.
  • The Apify server responds with Content-Type: application/json.

The 406 error is generated internally by the UiPath framework as a generic failure code after it fails to process the Location header. This behavior is highly misleading and directs debugging efforts toward non-existent content-type or header mismatch issues. Similar platform-level issues resulting in a 406 error have been observed in other contexts, such as publishing packages to Orchestrator, often stemming from permissions or server-side processing failures.

4. Conclusion and Recommendation for the UiPath Team

The root cause of this issue is a limitation in the UiPath Integration Service’s custom connector runtime. The framework cannot correctly handle a standard HTTP 201 Created response that includes a Location header, misinterpreting it as an unsupported redirect and subsequently raising a misleading 406 error.

This limitation severely hinders the ability to create robust custom connectors for modern, asynchronous APIs that adhere to common RESTful design patterns.

Could you please advise with what is going on? It really seems as an issue in Response mapping in UI path :confused:
Thanks!