For the complete documentation index, see llms.txt. This page is also available as Markdown.

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 failures

  • NodeOperationError: 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

Feature availability

Failure declarations are available from n8n 3.37.

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.

Field
Meaning

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?