Skip to content

Releases: UiPath/uipath-llm-client-python

UiPath LangChain Client [langchain-v1.15.2]

Choose a tag to compare

@github-actions github-actions released this 03 Jul 11:19
c1facdd

[1.15.2] - 2026-07-03

Changed

  • Bumped uipath-llm-client to >=1.15.1, which requires uipath-platform>=0.1.91 (fixes a circular-import crash in 0.1.89/0.1.90).

UiPath LLM Client [v1.15.0]

Choose a tag to compare

@github-actions github-actions released this 26 Jun 14:36
58680d2

[1.15.0] - 2026-06-25

Added

  • UiPathError — a common root exception for everything the client can raise, re-exported from uipath.llm_client. UiPathAPIError (and therefore every status-specific subclass) now inherits from it, so except UiPathError is a single catch-all across all backends and providers. Fully backward compatible: UiPathAPIError still inherits httpx.HTTPStatusError and all existing handlers keep working.
  • as_uipath_error(exc) and the wrap_provider_errors() context manager (in uipath.llm_client.utils.exceptions). They convert a provider/SDK exception into the matching UiPath exception so callers handle one taxonomy regardless of which provider produced the error. The cause chain (__cause__/__context__) is walked for an httpx.Response; when found, its status code is mapped onto the corresponding UiPathAPIError subclass (a 429 → UiPathRateLimitError, a 400 → UiPathBadRequestError, …) so semantic handling is identical across providers — including providers (e.g. Google) that wrap the response-bearing error one level down. When no response is available anywhere in the chain (client-side validation errors, connection failures) the UiPathError root is returned. The original provider exception is preserved as __cause__.

Changed

  • UiPathRateLimitError.retry_after is now parsed lazily from self.response (via a property) instead of being cached in __init__. _parse_retry_after and the parsing behaviour are unchanged.
  • patch_raise_for_status now routes the httpx HTTPStatusError through wrap_provider_errors, so direct raise_for_status() callers and provider SDK exceptions share a single conversion path. The raised UiPathAPIError now carries the original HTTPStatusError as __cause__ (previously None); status mapping is unchanged.

Note

  • Provider errors are surfaced as pure UiPath types: an openai.RateLimitError raised through a passthrough chat model becomes a UiPathRateLimitError and is not catchable as openai.RateLimitError (the vendor exception is kept as __cause__). Standardise handlers on UiPathError and its subclasses.

UiPath LangChain Client [langchain-v1.15.0]

Choose a tag to compare

@github-actions github-actions released this 26 Jun 14:38
2c066c0

[1.15.0] - 2026-06-25

Added

  • UiPathBaseChatModel now converts provider SDK exceptions into UiPathError. When any chat client (UiPathChatOpenAI, UiPathChatAnthropic, UiPathChat, Bedrock/Vertex/Google/LiteLLM/Fireworks, …) raises during _generate/_agenerate/_stream/_astream, the error is converted into the matching UiPath semantic subclass (a 429 → UiPathRateLimitError, a 400 → UiPathBadRequestError, …) — including providers like Google that wrap the response-bearing error one level down — giving provider-agnostic error handling across every client. Errors without an HTTP response (e.g. client-side validation) become the UiPathError root. UiPathError is re-exported from uipath_langchain_client.

Changed

  • Bumped uipath-llm-client floor to >=1.15.0 to pick up UiPathError and the wrap_provider_errors / as_uipath_error helpers.

Note

  • Provider errors are now surfaced as pure UiPath types and are not catchable as their original vendor type (e.g. openai.BadRequestError); the vendor exception is preserved as __cause__. Standardise handlers on UiPathError and its subclasses.

UiPath LangChain Client [langchain-v1.14.1]

Choose a tag to compare

@github-actions github-actions released this 23 Jun 10:53
53fd47c

[1.14.1] - 2026-06-23

Fixed

  • WrappedBotoClient (the httpx-backed Bedrock shim) now calls raise_for_status() in converse, invoke_model, and the streaming generator before reading the response. Previously a non-2xx gateway response (e.g. 403 License-not-available) was parsed as a normal result and handed to langchain_aws, which raised a misleading ValueError("No 'output' key found in the response from the Bedrock Converse API ... misconfiguration of endpoint or region") — the real status code and detail were lost. Gateway HTTP errors now surface as the patched UiPathAPIError subclass (e.g. UiPathPermissionDeniedError), matching the OpenAI and Vertex paths. For streaming responses the error body is read first so the typed exception retains its detail.

UiPath LLM Client [v1.14.0]

Choose a tag to compare

@github-actions github-actions released this 16 Jun 08:06
cc7a3bf

[1.14.0] - 2026-06-15

Added

  • ApiFlavor.ANTHROPIC_MESSAGES ("AnthropicMessages") for Bedrock-hosted Claude models that the discovery endpoint exposes with the native Anthropic Messages wire format. The value is the discovery string verbatim because it is forwarded as the X-UiPath-LlmGateway-ApiFlavor header. Also mapped in API_FLAVOR_TO_VENDOR_TYPE to VendorType.AWSBEDROCK so it resolves to the Bedrock passthrough route when discovery omits the vendor field.

UiPath LangChain Client [langchain-v1.14.0]

Choose a tag to compare

@github-actions github-actions released this 16 Jun 08:08
cc7a3bf

[1.14.0] - 2026-06-15

Added

  • Support for the AnthropicMessages API flavor on Bedrock-hosted Claude models. get_chat_model now routes discovery's apiFlavor=AnthropicMessages (vendor AwsBedrock) to UiPathChatAnthropic configured with vendor_type=awsbedrock and api_flavor=ApiFlavor.ANTHROPIC_MESSAGES. The client keeps the Bedrock passthrough URL but uses the native Anthropic/AsyncAnthropic SDK (model-in-body wire format), which the gateway requires for this flavor, instead of AnthropicBedrock.
  • UiPathChatAnthropic now accepts an explicit api_flavor. When set to ApiFlavor.ANTHROPIC_MESSAGES it selects the native Anthropic SDK regardless of vendor_type; otherwise the flavor and SDK are derived from vendor_type exactly as before (awsbedrockinvoke + AnthropicBedrock, unchanged).

Changed

  • Bumped uipath-llm-client floor to >=1.14.0 to pick up ApiFlavor.ANTHROPIC_MESSAGES.

UiPath LLM Client [v1.13.1]

Choose a tag to compare

@github-actions github-actions released this 09 Jun 13:18
80f46a9

[1.13.1] - 2026-06-09

Fixed

  • PlatformSettings now accepts non-JWT access tokens (e.g. opaque UiPath reference tokens) for UIPATH_ACCESS_TOKEN. Previously any token that was not a parseable JWT failed validation with "Invalid access token: expected JWT with at least 2 dot-separated parts". Token introspection is now best-effort: is_token_expired returns False when the token is not a parseable JWT, and the settings validator only extracts client_id when the token is a parseable JWT. Added try_parse_access_token helper in uipath.llm_client.settings.platform.utils.

UiPath LangChain Client [langchain-v1.13.1]

Choose a tag to compare

@github-actions github-actions released this 09 Jun 13:22
80f46a9

[1.13.1] - 2026-06-09

Fixed

  • Picks up the core uipath-llm-client 1.13.1 fix allowing non-JWT access tokens (e.g. opaque UiPath reference tokens) as UIPATH_ACCESS_TOKEN, so LangChain clients built on PlatformSettings no longer fail validation with "Invalid access token: expected JWT with at least 2 dot-separated parts".

UiPath LLM Client [v1.13.0]

Choose a tag to compare

@github-actions github-actions released this 28 May 10:11
3c8ebcc

[1.13.0] - 2026-05-27

Added

  • UiPathRequestTimeoutError (HTTP 408) and UiPathBadGatewayError (HTTP 502) exception classes. Both are registered in _STATUS_CODE_TO_EXCEPTION, re-exported from uipath.llm_client, and inherit from UiPathAPIError for compatibility with existing handlers.

Changed

  • Default retry set expanded. _DEFAULT_RETRY_ON_EXCEPTIONS in uipath.llm_client.utils.retry now covers UiPathRequestTimeoutError (408), UiPathRateLimitError (429), UiPathBadGatewayError (502), UiPathServiceUnavailableError (503), UiPathGatewayTimeoutError (504), and UiPathTooManyRequestsError (529) — up from {429, 529}. Applies to every provider client (UiPathOpenAI, UiPathAnthropic*, UiPathGoogle) since they all share the same UiPathHttpxClient-backed retry transport. Retry-After / x-retry-after headers and exponential backoff with jitter behave as before.
  • UiPathHttpxClient / UiPathHttpxAsyncClient default max_retries raised from 0 to 3. Callers that pass max_retries=None (or omit it entirely) now get 3 retries by default. Pass max_retries=0 explicitly to opt out — max_retries=0 continues to disable retries, so the opt-out path is unchanged.

UiPath LangChain Client [langchain-v1.13.0]

Choose a tag to compare

@github-actions github-actions released this 28 May 10:12
3c8ebcc

[1.13.0] - 2026-05-27

Changed

  • UiPathBaseLLMClient.max_retries field default raised from 0 to 3. Every LangChain chat and embedding client built on this base (UiPathChat, UiPathChatOpenAI, UiPathAzureChatOpenAI, UiPathChatAnthropic, UiPathChatAnthropicBedrock, UiPathChatBedrock, UiPathChatBedrockConverse, UiPathChatVertexAI, UiPathChatFireworks, UiPathChatLiteLLM, plus the matching embeddings classes) now retries failed requests 3 times by default. Pass max_retries=0 explicitly to disable retries — the opt-out path is unchanged. Combined with the expanded default retry set in uipath-llm-client 1.13.0, every LangChain client now retries on HTTP 408, 429, 502, 503, 504, and 529 out of the box.
  • Bumped uipath-llm-client floor to >=1.13.0 to pick up the expanded default retry set and the new UiPathRequestTimeoutError / UiPathBadGatewayError typed exceptions.