BlueBubblesClient returns a CancelablePromise that rejects with an ApiError when the server responds with a non-2xx status code or when a network-level failure occurs. Understanding how to catch and inspect these errors — and how to cancel requests you no longer need — will make your integration more robust and easier to debug.
The ApiError class
When a request fails, the SDK throws an instance of ApiError, which extends the native Error class. It carries the full context of both the request that was sent and the response that was received.
| Property | Type | Description |
|---|---|---|
status | number | The HTTP status code returned by the server (e.g. 401, 404, 500). |
statusText | string | The HTTP status text associated with the status code (e.g. "Unauthorized"). |
url | string | The full URL of the request that failed. |
body | any | The parsed response body. For BlueBubbles Server errors this is typically a JSON object. |
request | ApiRequestOptions | The original request options — method, URL template, headers, query params, and body — that produced the error. |
ApiError also inherits message and name ("ApiError") from Error, so you can log it directly or pass it to error-reporting tools without losing information.
Catching errors with try/catch
Wrap any SDK call in a standardtry/catch block. Import ApiError from the package so you can narrow the type of the caught value before accessing its properties.
err instanceof ApiError before reading SDK-specific properties. Any other thrown value is a bug in your application code or an unexpected runtime error, and you should let it propagate.
Checking specific status codes
Different status codes require different recovery strategies. The most common ones you will encounter with the BlueBubbles Server are shown below.401 Unauthorized — wrong or missing password
401 Unauthorized — wrong or missing password
404 Not Found — resource does not exist
404 Not Found — resource does not exist
The requested resource (message, chat, attachment, handle) was not found. Check that the GUID or identifier you are passing is correct.
500 Internal Server Error — server-side failure
500 Internal Server Error — server-side failure
BlueBubbles Server encountered an unexpected error. The
body property often contains a descriptive message from the server. These errors are not caused by your request and typically require checking the server logs.Complete error-handling pattern
The pattern below handles the full range of outcomes — success, known API errors, and unexpected failures — in one place. Adapt it to your own error-reporting infrastructure.BlueBubbles Server returns
401 Unauthorized for every request when the password is missing or wrong, including calls to endpoints that appear to be read-only. If you see a flood of 401 errors across multiple services, the most likely cause is a misconfigured PASSWORD in your OpenAPIConfig rather than a per-endpoint permission issue.Canceling requests with CancelablePromise
Every SDK method returns a CancelablePromise<T> — a Promise subclass that adds a cancel() method. Calling cancel() aborts the underlying fetch and causes the promise to reject with a CancelError instead of resolving or throwing ApiError.
Use cancel() when you need to abandon a request that is no longer relevant — for example, when the user navigates away, a component unmounts, or a newer request supersedes an older one.
Hold a reference to the CancelablePromise
Do not immediately
await the promise if you might need to cancel it. Keep a reference so you can call cancel() later.Assign the request and handle CancelError
Catch
CancelError separately so you can distinguish an intentional cancellation from a real failure.Inspecting cancellation state
CancelablePromise exposes an isCancelled getter so you can check the current state synchronously without awaiting the promise.