Error handling
Proper error handling is crucial for creating robust n8n nodes that provide clear feedback to users when things go wrong. n8n provides two specialized error classes to handle different types of failures in node implementations:
NodeApiError: For API-related errors and external service failuresNodeOperationError: For operational errors, validation failures, and configuration issues
NodeApiError
Use NodeApiError when dealing with external API calls and HTTP requests. This error class is specifically designed to handle API response errors and provides enhanced features for parsing and presenting API-related failures such as:
HTTP request failures
external API errors
authentication/authorization failures
rate limiting errors
service unavailable errors
Initialize new NodeApiError instances using the following pattern:
new NodeApiError(node: INode, errorResponse: JsonObject, options?: NodeApiErrorOptions)Common usage patterns
For basic API request failures, catch the error and wrap it in NodeApiError:
try {
const response = await this.helpers.httpRequestWithAuthentication.call(
this,
credentialType,
options
);
return response;
} catch (error) {
throw new NodeApiError(this.getNode(), error as JsonObject);
}Handle specific HTTP status codes with custom messages:
NodeOperationError
Use NodeOperationError for:
operational errors
validation failures
configuration issues that aren't related to external API calls
input validation errors
missing required parameters
data transformation errors
workflow logic errors
Initialize new NodeOperationError instances using the following pattern:
Common usage patterns
Use NodeOperationError for validating user inputs:
When processing multiple items, include the item index for better error context:
Declaring why an operation failed
Both NodeApiError and NodeOperationError accept a failure option that states why the operation failed. Use it when the node can tell from the response what went wrong, such as a used-up quota or a credential that no longer works. The declaration lands on the error's failure property as plain data. The node states the cause, never what to do about it: n8n owns any behavior derived from the declaration, such as how a polling trigger backs off after a failed poll.
Pass the declaration when you construct the error:
Failure causes
The cause field takes one of six values. The first three describe failures that resolve on their own. The other three need someone to act before the operation can succeed.
cause
Meaning
rate-limited
The service is throttling requests.
quota-exhausted
A usage quota ran out and the operation fails until the quota resets.
temporarily-unavailable
The service is down or degraded right now.
credential-invalid
The credential no longer works. The user has to reconnect it.
configuration-invalid
The node points at something that no longer exists or is no longer allowed.
node-defect
A bug in the node itself. Neither the credential nor the configuration is to blame.
Wait hints
On rate-limited, quota-exhausted, and temporarily-unavailable, you can add optional hints about when the operation may work again. The other causes don't accept them, since there's nothing to wait for.
retryAfterMs
Minimum wait the service asked for, in milliseconds.
resetsAtEpochMs
When the service says the operation works again, as Unix epoch milliseconds.
For example, a quota that resets at a known time declares when it comes back:
Classifying API errors
Only declare a cause the response proves. If you can't classify an error with confidence, throw it unchanged: an error without a declaration is still valid.
Last updated
Was this helpful?