Meldport

Connect n8n to Meldport

Use n8n's generic HTTP Request node for one non-streaming Chat Completions request. Keep the key in credentials and inspect the first result before adding automation.

On this page

Reference release: n8n 2.45.7; HTTP Request node version 4.5. Documentation and release source checked 3 November 2026. This guide covers the explicit Chat Completions HTTP workflow. It does not certify every OpenAI node, Responses mode or autonomous agent configuration.

Prepare a small, manual workflow

Create a dedicated Meldport API key with the inference scope and limits appropriate for a test. Verify your email and choose an exact active ID from the published model catalog. A :free alias uses the shared monthly pool; a paid ID needs the appropriate funding.

The downloadable example currently selects deepseek-v4.1-flash-1017:free. It requests at most 64 output tokens, sets stream: false, starts manually and disables automatic retry on the HTTP node.

Download the n8n workflow JSON. Import it into a test workflow. It contains no API key or credential identifier; select your own credential before running it.

Configure credentials and the HTTP node

  1. Add a Manual Trigger and an HTTP Request node, or import the download.
  2. Create a generic Header Auth credential. Name the header Authorization and set its value to Bearer followed by your dedicated key. Store that value in n8n credentials, not the workflow body, source repository or a URL query.
  3. On HTTP Request, choose POST, Generic Credential Type and Header Auth. Select the credential you created.
  4. Set the full URL to https://dev-api.meldport.com/v1/chat/completions. A generic HTTP node needs the complete endpoint, including /v1/chat/completions; this differs from SDKs that take a base URL ending at /v1.
  5. Enable Send Body, choose JSON, and use the model ID, user message, max_tokens: 64 and stream: false from the example. Use JSON content type.
  6. Execute once manually. Check the message and token usage before enabling a schedule or processing many input items.

What a successful test returns

A successful execution returns HTTP 200 with a nonempty message at choices[0].message.content and token counts in usage.prompt_tokens, usage.completion_tokens, and usage.total_tokens. For example, the returned message can explain that a gateway routes model requests through one API. Wording and token counts depend on the selected model.

The HTTP Request node shows the response body by default. To also see the HTTP status and request reference, open Options → Response and turn on Include Response Headers and Status before your test. Check statusCode, find x-request-id in headers, and read the message and token counts under body. Confirm that the trigger sent one item and match the request reference to one entry in Meldport Usage before activating the workflow.

On 6 November 2026, n8n 2.45.7 imported the downloaded workflow and executed one request for deepseek-v4.1-flash-1017:free against a local test endpoint. The HTTP node sent the credential header and 64-token limit, then read the expected JSON response. This verifies workflow execution against a fixture. Live model usage and charges need a separate check.

Text, streaming and tools have different contracts

This workflow consumes one complete JSON response. It does not parse an SSE stream or execute returned tool calls. For a tool loop, your workflow must validate the returned tool name and arguments, run only an allowed action, send the matching tool result, and bound subsequent turns. A model's tool capability alone does not create that orchestration.

Some n8n AI nodes and modes can expect a different OpenAI protocol. Use the operation documented for the exact version and inspect the endpoint actually called. Do not switch to Responses or Anthropic Messages and assume the Meldport Chat Completions contract changed. This guide is deliberately limited to the HTTP Request node shown above.

Handle errors and costs before retrying

  • 401 or 403: verify the credential, key scope, email verification and environment. Never paste the key into an execution log to debug it.
  • Model not found: compare the exact API ID with the active catalog. Display names, OpenRouter IDs and page slugs can differ.
  • Free quota or wallet limit: check the shared allowance, account and key fallback permissions, balance and reservation requirement. Moving to another free model does not reset the pool.
  • 429: inspect the reported limit and Retry-After when present. Reduce concurrency or incoming items before adding bounded backoff.
  • Timeout, disconnect or reconciliation: inspect Usage and the request reference before rerunning. A new execution can create another billable request; this example does not promise an automatic refund or safe retry after an uncertain outcome.

Review execution-history retention in n8n because workflow inputs and model outputs can contain sensitive content. Keep test data small and non-sensitive. Once the first request works, use the workload calculator to budget all items, tool turns and possible retries, rather than only the first message.

Sources and validation boundary

The workflow structure follows the official HTTP Request documentation and credential documentation. Node version 4.5 is listed in the pinned n8n release source. The request body follows Meldport's API contract. Client/runtime and real-provider checks are recorded separately during release QA; no provider performance benchmark is claimed here.

For another client, compare OpenCode and Cline. For support, send a redacted request reference and error code through Meldport contact.