DeepSeek API Strict Tool Calling Through a Gateway

Your DeepSeek API request returns a tool call. The function name looks correct. The arguments are valid JSON.

Then your application rejects them.

Perhaps a required field is missing. Perhaps a quantity arrives as a string. Perhaps the model adds an argument your function does not accept. The connection works, but the integration is still unreliable.

For developers using an API gateway, this creates a more precise question than “Does this provider support DeepSeek?”

Does this particular DeepSeek route preserve the tool-calling behavior my application depends on?

This guide explains how to investigate that question with a small, read-only test. You will define a tool contract, examine the gateway boundary, and distinguish schema compliance from business correctness.

The goal is to finish with evidence about one usable model route—not a successful “hello world” request.

Start with three different meanings of “valid”

A tool call can pass one check and fail the next.

Consider a tool that looks up a product by SKU.

The following arguments are valid JSON:

{
  "sku": 123,
  "include_internal_notes": true
}

They may still violate your contract if sku must be a string and additional properties are forbidden.

Now consider:

{
  "sku": "SKU-DOES-NOT-EXIST"
}

This might satisfy the schema perfectly. It does not prove the product exists.

Keeping those boundaries separate prevents a common integration mistake: treating structured output as permission to execute an operation.

What DeepSeek strict mode actually changes

DeepSeek documents strict tool calling as a Beta feature. Its direct API instructions specify the Beta base URL, strict: true on function definitions, and a supported subset of JSON Schema.

For object schemas, the documented rules include declaring properties as required and setting additionalProperties to false. Schema configurations outside the supported specification may be rejected.

See the DeepSeek tool-calling documentation for the current requirements.

Those are DeepSeek’s direct API requirements. A third-party gateway needs an explicit implementation of the same behavior.

Do not invent a gateway Beta URL by adding /beta to an existing address. A gateway may expose the feature differently, or may not expose it on your selected route.

The distinction matters because a successful ordinary tool call does not establish strict-mode support.

Build a tool that cannot change anything

For your first experiment, use a read-only function. A product lookup, document lookup, or configuration lookup works well.

Avoid starting with a function that sends messages, changes permissions, or creates an order. You want to inspect the arguments without introducing business side effects.

Here is a small tool definition:

{
  "type": "function",
  "function": {
    "name": "lookup_product",
    "description": "Look up one product using the SKU supplied by the user.",
    "strict": true,
    "parameters": {
      "type": "object",
      "properties": {
        "sku": {
          "type": "string"
        }
      },
      "required": ["sku"],
      "additionalProperties": false
    }
  }
}

This is a schema example, not a complete request.

Use a simple prompt:

> Look up product SKU-DEMO-104. Use the product lookup tool.

The expected argument structure is deliberately small:

{
  "sku": "SKU-DEMO-104"
}

A tiny contract makes failures easier to explain. If your first test contains twelve nested objects, optional fields, multiple tools, and a long conversation, you will spend more time deciding which feature caused the problem.

Identify the exact route before testing

Open the 4SAPI model pricing page and your account’s model catalog. Record the exact model identifier and the group associated with the API token.

Then inspect the 4SAPI tool-calling endpoint documentation.

The documented general tool interface uses:

POST https://4sapi.com/v1/chat/completions

That identifies a general interface. It does not independently confirm DeepSeek strict-mode support.

Before relying on strict behavior, establish:

• The exact DeepSeek model identifier available to your token.
• Whether that route supports ordinary tool calls.
• Whether it explicitly supports DeepSeek’s strict tool schema behavior.
• Which endpoint and request settings enable that behavior.
• How unsupported parameters and unsupported schemas are reported.

This is a useful question to send to a provider:

> For this model ID and token group, is tools[].function.strict enforced, rejected, or ignored? Which endpoint should I use, and can you provide a minimal supported request?

That question is more actionable than asking whether the gateway is “fully compatible.”

Run the experiment in stages

Start with a normal, non-streaming tool request using the smallest supported configuration.

Next, enable strict mode using the route’s documented settings. Keep the model, prompt, and tool definition otherwise unchanged.

Do not force a tool by copying parameters from an unrelated model tutorial. DeepSeek’s current Chat Completions documentation distinguishes tool-choice behavior by thinking mode. Check the DeepSeek request reference before combining those settings.

For each response, inspect:

1. Whether a tool call was returned.
2. Whether the function name matches the one you supplied.
3. Whether the arguments decode as JSON.
4. Whether they satisfy your schema.
5. Whether the SKU matches the user’s request.
6. Whether the response finished normally.

Do not execute the function yet. Print or store the proposed arguments in a controlled development environment.

A response without a tool call should be recorded separately. It is not automatically a malformed tool call; tool selection and argument validation are different questions.

Validate locally even when strict mode is available

Here is a minimal local validator for the example contract:

import json

def validate_lookup_arguments(arguments_json: str) -> dict:
    arguments = json.loads(arguments_json)

    if not isinstance(arguments, dict):
        raise ValueError("Tool arguments must be an object")

    if set(arguments) != {"sku"}:
        raise ValueError("Expected exactly one field: sku")

    sku = arguments["sku"]

    if not isinstance(sku, str):
        raise ValueError("sku must be a string")

    if not sku.strip():
        raise ValueError("sku must not be blank")

    return arguments

This function is intentionally specific. It is not a general JSON Schema validator.

For larger contracts, use a maintained JSON Schema validation library and keep your application’s business checks separate.

Notice that the example rejects an empty SKU even though the earlier schema only requires a string. That extra rule belongs to the application’s acceptance criteria.

You should also verify that the current user is allowed to look up the requested record. No model output should replace that authorization check.

Add a few deliberately awkward requests

A single successful example can hide a weak integration.

Try a small set of cases:

These cases test more than syntax. They show whether the model and your application can work together without silently guessing.

An invented SKU may still be schema-valid. Record it as a semantic failure.

Likewise, repeated schema-valid responses are useful evidence, but they do not prove that the gateway enforces strict mode. Documentation, configuration, and observed behavior need to agree.

If it fails, preserve the evidence

Save a small diagnostic record containing:

• Model identifier and token group label.
• Endpoint path.
• Relevant request parameters.
• Schema version.
• HTTP status.
• Response or request identifier, when available.
• Whether the failure occurred before or after generation.

Remove credentials and private input before sharing it.

If ordinary tools work but strict requests fail, you have narrowed the problem considerably. Possible causes include unsupported schema features, incompatible settings, or a gateway route that does not implement the Beta capability.

If both requests fail, return to the basic model access configuration first.

For conversation-state problems after a successful first call, use the separate DeepSeek Responses API state guide. Do not assume a schema problem and a multi-turn state problem have the same fix.

What a useful gateway evaluation should produce

Your final result should be a short statement such as:

> This DeepSeek model route accepts our lookup schema, preserves the expected tool-call structure, and passes the five development cases. Strict-mode support is documented for this route. Application validation remains enabled.

Or:

> Ordinary tool calls work, but strict-mode enforcement is unconfirmed. This route is not approved for workflows that require that guarantee.

Both are useful outcomes. The second prevents an unreliable integration from reaching production.

If you are evaluating 4SAPI, create an account and follow the API setup guide to identify the model and group before running a small test. Confirm the advanced feature before adding a substantial balance.

Your first milestone is not collecting another API key. It is getting one DeepSeek route to satisfy a contract your application can verify.