fix(runtime): handle error respons correctly #92
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR fixes an issue where the SDK did not return a clear or useful error response when an API request failed.
Previously, the
request()method threw anApiExceptionwith the rawResponseobject, without parsing its JSON body.As a result, applications could not access the actual error message returned by the Zitadel API.
This PR updates the method to parse the error body via
response.json()and pass the parsed data intoApiException, enabling clearer debugging and proper error handling.Related Issue
No official GitHub issue existed. This bug was discovered during real-world integration of the Zitadel Node SDK.
Motivation and Context
When the Zitadel API returned an error response (e.g., 400/401/404), the SDK exposed only a generic
Response returned an error codemessage.Critical information—such as error codes, messages, or details returned by the Zitadel backend—was not available to the developer.
This made debugging and error handling difficult.
By parsing and forwarding the JSON error body, developers now receive:
This greatly improves the developer experience when using the SDK.