n8n HTTP Request, Code node, custom node or separate service?

Start with an existing supported integration when it covers the operation you need. If it does not, an n8n HTTP Request node is often enough to call the API. Use a Code node for bounded data transformation, a custom node for a reusable integration interface, and a separate service when the product needs an independently operated boundary. The right choice can combine these rather than replace n8n.

n8n already supports code inside workflows, and self-hosting is an option. So the decision is not simply no-code versus code, or a cloud tool versus your own server. It is where credentials, business rules, state, tests and operational ownership should live.

Compare the smallest option that meets the requirement

A custom node is not automatically a separate business service. It can provide a convenient n8n interface to an API while the API owns the actual records and rules. Conversely, moving ten lines of transformation into a service can add a deployment and network failure without solving a real boundary problem.

Use one example to expose the tradeoffs

Consider a synthetic support workflow. Every hour it reads newly opened requests from an API, validates the fields, prepares a short AI summary and presents a draft to an operator. The operator may choose to create a follow-up task. The example API paths and identifiers below are invented for explanation; this is not an importable n8n template or a claim about a delivered client system.

Illustrative API contract
GET /v1/requests?cursor=<next_cursor>
  → items: [{ id, revision, status, summary }], next_cursor

Read → validate → prepare draft → human decision
  → create task with a stable business operation reference
  → record confirmed or uncertain outcome

Assumption to verify: the real target API's authentication,
pagination, rate limits and support for idempotent writes.

HTTP Request: make the API call explicit

Use an HTTP Request node for the read operation if the target API exposes it. Keep authentication in the supported credential mechanism, configure the method and query parameters, and follow the provider's pagination contract. Test the first page, the final page, an empty result and an error response. A cursor that never advances can create repeated work even though each individual request succeeds.

Read rate-limit responses and bounded retry rules from the actual provider. An API call that creates a task needs a different retry policy from a read. If the service supports idempotency keys, follow its documented scope and retention rules. If it does not, a local operation reference still helps trace attempts, but it cannot guarantee that a timed-out create operation did not happen.

Code node: transform a bounded set of records

A Code node can normalise known status names, reject records without an identifier, or construct a compact input for the model. Choose Run Once for All Items or Run Once for Each Item according to what the code expects. Confusing a batch with a single item can drop records or attach a result to the wrong request.

The Code node supports JavaScript or Python, with capabilities depending on the execution environment and configuration. Use the documented nodes for HTTP and file operations where required instead of assuming every local language feature is available in a hosted runtime. Keep transformation code small enough that an empty value, unexpected type and multiple input items can be tested directly.

Custom node: package a repeated integration, not every repeated line

A custom node becomes more attractive when several maintained workflows need the same service, credential type and operations. Named fields and shared pagination or error behaviour can reduce repeated configuration. That benefit comes with package maintenance: versioning, compatibility, tests, installation policy and documentation for the operators who use it.

Before building one, list the operations that should be stable, such as List requests and Create follow-up task. Define how errors reach the workflow and which provider features remain configurable. Review the deployment environment's current node installation policy; do not assume a private or community package can be installed in every managed account.

Separate service: own a business boundary with a clear reason

A service can own submission identities, permissions, durable jobs and a reconciliation queue shared by the bot, operator interface and n8n workflow. It is useful when these responsibilities need their own lifecycle or apply across multiple entry points. The n8n workflow can still orchestrate the process and call that service through HTTP.

That choice also creates operational work: deployments, configuration, storage, access checks, monitoring and on-call recovery. Write down the reason for the boundary. Independently scaling a long processing job is a reason; a preference for writing code is not enough to justify an additional production dependency.

Approval and retries need the same care in every option

In the support example, the model proposes a summary and draft action. Fixed rules and the operator decide whether a follow-up task may be created. Tie the decision to the reviewed request revision and intended destination, then recheck those conditions before execution. Editing the draft should not preserve permission for an older proposal.

Distinguish input received, draft prepared, decision recorded, action attempted and result confirmed. A green workflow execution is not enough evidence that an external task exists, and a timeout is not proof that it does not. Keep the target identifier when returned, and route unresolved outcomes to a deliberate recovery path.

Before choosing, run this small acceptance exercise

• Read more than one page and confirm that every expected record appears once in the intended processing set.
• Supply an empty response and a malformed record; require a clear outcome rather than a silent partial result.
• Return a rate-limit error and verify the bounded delay and retry policy.
• Change the source revision or destination after review and ensure the old decision cannot authorise the changed action.
• Lose the create-task response after acceptance; verify the uncertain-outcome procedure before repeating the side effect.
• Ask the person maintaining the workflow to locate credentials, validation rules, failed operations and release instructions.

Start with the simplest option that passes the exercise. Keep HTTP calls and small transformations in the workflow when that remains clear. Introduce a custom node for a maintained integration surface, or a service for independently owned business state. Revisit the choice when the requirements change, not merely when another node is added.

Built from the work.WeMAIde designs and ships AI software, apps, Telegram products and automation systems.