How to Call an OpenAI-Compatible API from Make.com

Short path: LLM API gateway · Production LLM API · OpenAI-compatible API · Usage logs

Last verified: August 3, 2026

To connect Make.com to an OpenAI-compatible API, use the current HTTP V4 app, choose an API-key-authenticated request, store the full Bearer value in Make's encrypted keychain and send JSON to /v1/chat/completions. This route is more portable than assuming a native OpenAI module exposes every custom provider or base URL.

For LumeAPI, the endpoint is https://api.lumeapi.site/v1/chat/completions.

Build the minimum scenario

Manual trigger
    ↓
Tools: Set variable (prompt)
    ↓
HTTP V4: Make an API key auth request
    ↓
Tools: Set variable (answer)

Start with a manual run. A scheduled scenario can multiply a configuration error across many bundles and consume credits or model usage before you notice it.

Create the secure API-key connection

In the HTTP V4 module, choose API key authentication and create a keychain entry:

Make's API-key authentication documentation expects the complete required prefix in the key value. In this case, include Bearer before the key. This keeps the credential in Make's keychain instead of a visible scenario field.

Do not use the Research ingest key. It is for publishing site content, not inference.

Configure the HTTP V4 request

Use:

Map this JSON body, replacing the prompt value with the output of your previous module:

{
  "model": "gpt-5.4-mini",
  "messages": [
    {
      "role": "system",
      "content": "Return a concise answer. Do not invent missing facts."
    },
    {
      "role": "user",
      "content": "{{prompt}}"
    }
  ],
  "temperature": 0
}

Run the module once with Reply with exactly: Make connection ok. Make needs a sample execution before downstream modules can reliably expose parsed response fields.

Map only the fields the next step needs

From the parsed response, map:

answer           = choices[1].message.content
request_id       = id
served_model     = model
prompt_tokens    = usage.prompt_tokens
completion_tokens = usage.completion_tokens

Make's visual mapping may show the first array item as index 1. Confirm the displayed path from the actual output bundle instead of typing a guessed expression.

Keep the raw response available for debugging, but avoid passing the entire payload into email, CRM or chat modules. A narrow output contract reduces accidental logging and prevents downstream mappings from depending on irrelevant provider fields.

Add error handling before scheduling

Attach an error-handler route to the HTTP module:

Do not add a generic infinite repeater after the HTTP node. A scenario with multiple input bundles can create a retry storm. Cap attempts, use jitter and carry a stable job ID so a later email, payment or record creation is idempotent.

Avoid one model call per uncontrolled bundle

Make scenarios often fan out. Before the AI request:

1. Count bundles and stop unexpectedly large runs.
2. Filter empty or duplicate input.
3. Aggregate compatible items when one prompt can handle a batch.
4. Limit prompt length.
5. Select models from an allowlist.
6. Require approval before irreversible actions.

The model call and the Make operation are separate cost units. Track scenario executions, HTTP attempts, input/output tokens and successful business outcomes. The meaningful metric is cost per accepted result, not cost per request.

When to use a native module instead

A native OpenAI module is convenient when it supports the exact provider, endpoint, model and response shape you need. Use HTTP V4 when you need a custom OpenAI-compatible base URL, explicit authentication, a visible JSON contract or predictable portability across model vendors.

The HTTP V4 route also makes migrations easier: change the keychain, base URL and allowlisted model while leaving the surrounding scenario unchanged. Still test optional features such as tools, structured output and streaming separately; “OpenAI-compatible” does not mean every vendor-specific extension is identical.

Production checklist

• The key is in Make's encrypted keychain, not a text field.
• The URL includes /v1/chat/completions exactly once.
• A live model ID came from the model catalog.
• The response parser has seen a successful sample bundle.
• 400/401 errors stop instead of retrying.
• 429/5xx retries are capped.
• Large bundle counts are rejected or batched.
• Prompts containing personal data have an explicit retention policy.
• Downstream side effects have idempotency protection.

Sources and verification boundary

• Make HTTP V4 app documentation
• Make API-key authentication
• Make announcement: HTTP V4 secure keychain and JSON structures
• LumeAPI production API guide

The HTTP V4 field map and request JSON were checked against Make's current public documentation on August 3, 2026. No logged-in Make scenario or customer inference key was available in the editorial workspace, so run the one-bundle manual test before enabling a schedule.