OpenAI function calling: how to safely connect AI to an API

What is function calling in simple terms

A standard model responds with text. But it doesn't know an order status, the weather, or a balance without access to an up-to-date source. Function calling allows you to describe an available action — for example, get_order_status — and give the model its name, purpose, and JSON Schema arguments.

When a user asks "Where is my order 4821?", the model can return a structured call with order_id: "4821". It does not run the function. Your application code receives the proposal, verifies it, calls its own database or API, and then passes the result back to the model. Only after that does the model formulate a human response.

This is useful for support bots, CRMs, internal assistants, and automations. At the same time, this is exactly where the risk arises: user text begins to influence real actions. Therefore, arguments from the model should be treated as untrusted input, just like form data.

How a single call works

1. The application sends a request. Along with the message, it passes only the tools needed for this specific time to the model.
2. The model proposes a function. An element appears in the response function_call with a name, JSON arguments, and a unique call_id.
3. The server checks the boundaries. The name is in the allowlist, arguments are valid, the user is authorized, and the action is permitted.
4. The server executes its own code. Database keys and external API keys are never passed to the model.
5. The result is returned to the model. The element function_call_output is linked to the call via call_id.
6. The model explains the result. The final answer relies on the actual data from the tool.

The OpenAI Responses API can return zero, one, or several calls. In the first version of the integration, it is better to set parallel_tool_calls: false: then the model will propose at most one tool per step, and the verification and retry logic will be simpler.

Function calling, Structured Outputs, or MCP

Don't force function calling to do what can be formatted as JSON. And vice versa: don't accept JSON text from the model as permission to change the database. Read more about a stable final format in the guide on Structured Outputs, and about the integration standard in the explanation of what MCP is.

Designing the smallest secure tool

For example, we take only reading the order status. We don't add refund_order, delete_order whether it is universal run_sql. The narrower the function, the easier it is to explain to the model, verify permissions, and write tests.

const tools = [{
  type: "function",
  name: "get_order_status",
  description: "Повертає статус замовлення поточного користувача.",
  strict: true,
  parameters: {
    type: "object",
    additionalProperties: false,
    properties: {
      order_id: {
        type: "string",
        pattern: "^[0-9]{4,12}$",
        description: "Номер замовлення з 4–12 цифр."
      }
    },
    required: ["order_id"]
  }
}];

strict: true forces arguments to match the supported schema. For strict functions, each object must contain additionalProperties: false, and all declared fields must be included in required. If a value can be missing, its type includes null.

The schema is the first boundary, but not authorization. We intentionally do not ask the model to pass user_id: otherwise it could substitute someone else's. The server takes the user ID from a verified session.

Full example via Responses API

Install the SDK and pass the key via an environment variable. The OpenAI key, database access, and user session must remain on the server.

npm install openai
export OPENAI_API_KEY="ваш_ключ"

import OpenAI from "openai";
import { toResponseInputItems } from
  "openai/lib/responses/ResponseInputItems";

const client = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY
});

// У production ці дані надходять із БД.
const orders = new Map([
  ["4821", { ownerId: "user_7", status: "paid", eta: "2026-10-03" }],
  ["7319", { ownerId: "user_9", status: "shipped", eta: "2026-10-02" }]
]);

const tools = [{
  type: "function",
  name: "get_order_status",
  description: "Повертає статус замовлення поточного користувача.",
  strict: true,
  parameters: {
    type: "object",
    additionalProperties: false,
    properties: {
      order_id: {
        type: "string",
        pattern: "^[0-9]{4,12}$"
      }
    },
    required: ["order_id"]
  }
}];

function getOrderStatus(args, authUserId) {
  if (!/^[0-9]{4,12}$/.test(args.order_id)) {
    return { ok: false, error: "invalid_order_id" };
  }

  const order = orders.get(args.order_id);
  if (!order || order.ownerId !== authUserId) {
    // Не повідомляємо, чи існує чуже замовлення.
    return { ok: false, error: "not_found" };
  }

  return { ok: true, status: order.status, eta: order.eta };
}

const authUserId = "user_7"; // У production — із перевіреної сесії.
const conversation = [{
  role: "user",
  content: "Який статус замовлення 4821?"
}];

let response = await client.responses.create({
  model: "gpt-6-astra",
  instructions: [
    "Допомагай лише зі статусом замовлення.",
    "Не вигадуй дані та не проси секрети.",
    "Відповідай українською."
  ].join(" "),
  input: conversation,
  tools,
  tool_choice: "auto",
  parallel_tool_calls: false
});

conversation.push(...toResponseInputItems(response.output));

for (const item of response.output) {
  if (item.type !== "function_call") continue;
  if (item.name !== "get_order_status") {
    throw new Error(`Заборонений інструмент: ${item.name}`);
  }

  let args;
  try {
    args = JSON.parse(item.arguments);
  } catch {
    args = { order_id: "" };
  }

  const result = getOrderStatus(args, authUserId);
  conversation.push({
    type: "function_call_output",
    call_id: item.call_id,
    output: JSON.stringify(result)
  });
}

response = await client.responses.create({
  model: "gpt-6-astra",
  instructions: "Поясни результат коротко українською.",
  input: conversation,
  tools,
  parallel_tool_calls: false
});

console.log(response.output_text);

A response like "Order 4821 is paid, expected date is October 3" only appears after the result of the server function. If the user user_7 request an order 7319, the server returns a general not_found and does not reveal that someone else's record exists.

Seven security boundaries for a real product

1. Least privilege. Give the tool access only to the necessary table, operation, and user. For Supabase, an additional boundary should be RLS policies.
2. A short allowlist. Pass only tools to the model that are relevant to the current screen or stage. The Responses API also supports tool_choice for forced or constrained selection.
3. Server-side validation. Verify type, format, length, range, record existence, and business rules after JSON.parse.
4. Authorization outside the model. The user, role, and organization are taken from the session or a verified token, not from the function arguments.
5. Human confirmation. Refunds, deletions, publishing, sending emails, and changing permissions must stop before the side effect.
6. Idempotency. Write operations receive a unique request key so that a network retry does not create two payments or two emails.
7. Secure logging. Log the tool name, validation result, and request ID, but not API keys, passwords, full personal data, or session tokens.

Prompt injection does not disappear through function calling. Text can command the model to ignore rules or call the wrong tool. A reliable answer is not a "stronger prompt," but technical boundaries: an unavailable function is not in the list, a forbidden argument blocks the code, and high risk requires confirmation.

How to test the integration before launch

Independently test external API timeouts, malformed JSON, access denial, empty results, and rate limits. For each case, the server should return a compact structured result, and the model should provide an honest explanation without a fabricated success.

Common mistakes

• One universal function execute_action(action, payload) hides the real level of risk. It is better to have several narrow functions with different permissions.
• Don't trust strict as a firewall. The schema controls the format, not the right to view a record or the security of the operation.
• User ID in the model arguments. It must be taken from an authorized session.
• Automatic logging immediately after the call. Checks are needed between the model's suggestion and the side effect, and confirmation is required for high-risk actions.
• All tools in every request. This increases the selection, complexity, and attack surface. Pass only the necessary subset.
• Secrets in the frontend. Store the OpenAI API key only on the server; if it leaks, use the plan with the key security guide.

Pre-production checklist

• Each function should have one clear purpose and minimal permissions.
• Enabled strict: true, additionalProperties: false, all fields are listed in required.
• The function name is checked via an allowlist; there is no eval or arbitrary SQL.
• Arguments are re-validated by the server.
• The user and role come from a verified session.
• Sensitive operations must have confirmation, limits, and an idempotency key.
• Errors do not reveal other people's records, secrets, or internal structure.
• There are tests for foreign IDs, prompt injection, incorrect formats, retries, and timeouts.
• Logs allow investigating the call without storing secrets.

Quick answers

Does OpenAI execute the function instead of the server?

No. The model only generates the name and arguments. Your code validates the request, executes the allowed function, and returns its result via function_call_output.

Is strict: true enough?

No. Strict stabilizes JSON arguments, but it doesn't check authorization, record ownership, limits, or consequences. That is the responsibility of the server and the database.

When is human confirmation needed?

Before irreversible, expensive, or public actions: payments, refunds, deletions, publishing, sending messages, and changing access rights.

How does function calling differ from Structured Outputs?

Structured Outputs forms a predictable final response. Function calling asks your application to run a tool, get the current result, and return it to the model.