DeepSeek API: how to use it, costs and business integration

The DeepSeek API is the interface through which an application can query DeepSeek models via a network request. Software sends instructions and data, the service returns a response and the application decides how to process it. The documentation offers formats compatible with the OpenAI and Anthropic APIs (DeepSeek).

In our guide to DeepSeek we introduced the platform and its models. Here we turn instead to integration: access, API key, first request, cost and the controls to put in place before feeding the output into a business process.

After all, a first successful call can confirm a technical connection, but to understand whether the integration is useful you need to observe it at work: which task it simplifies, which errors it introduces and how much time review takes. And the cost per token is only one part of this assessment.

What changes when using the DeepSeek API

With the DeepSeek APIs, the request can be prepared by software rather than typed in by a person each time. The program can send a text to be classified, receive a category and propose it to the operator handling the work.

One example is preparing a draft reply to a support request. The system collects the message, selects the authorised information and asks the model for a result in a defined format. The draft is then submitted to the person responsible for review.

For us, however, this step must be designed together with the destination of the output. An internal suggestion and a message sent to a customer have different consequences. The integration must know when it can proceed, when to request a check and when to stop.

DeepSeek API key: what you need before the call

A DeepSeek API key is the credential the software uses to authenticate the request. The official documentation directs users to the DeepSeek platform to obtain it. You should also check the available balance and the terms applicable to your account: access to the chatbot does not imply free use of the API (DeepSeek).

Before testing, we prepare a development environment, an authorised key and a short text containing no personal data or confidential information. The example in this guide uses an invented scenario and serves to illustrate the shape of the request.

The key must be stored in a controlled environment. In the demo code we read it from an environment variable, without placing it in the file. In a public project, the browser should call our server, which manages access to the service: publishing the credential in the JavaScript delivered to users would make it retrievable.

Credential management also requires an owner. You need to know who can create credentials, where they are used and how to revoke them. This information becomes useful when a supplier changes, a team member leaves the project or anomalous use is detected.

Which models to use with the DeepSeek API

DeepSeek API identifiers should be copied from the current documentation. As of 16 October 2026, the first-call guide lists deepseek-flash and deepseek-v4-pro. The former corresponds to the current Flash service; the documentation also describes how some older model names are handled (DeepSeek).

The name used in a guide from a few months ago may point to a different service or be outdated. In an integration, it is advisable to keep the model in an editable configuration and to record which identifier was used during testing.

To compare models, we prepare the same data and the same expected result. If prompt, version and materials all change at once, it becomes hard to tell which change produced an improvement. Moving to a new model must therefore include a fresh validation of the process.

How to make a first call to the DeepSeek API

To use the DeepSeek API, our example adopts the Chat Completions format. The endpoint is https://api.deepseek.com/chat/completions; the request includes authorisation and a JSON body. The DEEPSEEK_API_KEY variable must be configured in your own environment with a valid credential (DeepSeek).

curl –fail-with-body –max-time 30
https://api.deepseek.com/chat/completions
-H “Content-Type: application/json”
-H “Authorization: Bearer ${DEEPSEEK_API_KEY}”
-d ‘{
“model”: “deepseek-flash”,
“messages”: [
{
“role”: “system”,
“content”: “Write a draft faithful to the data provided.”
},
{
“role”: “user”,
“content”: “Summarise: prototype approved; delivery Friday.”
}
],
“thinking”: {“type”: “disabled”},
“max_tokens”: 400,
“stream”: false
}’

The code is an illustrative example checked against the documentation; it does not represent a test run with a real key. It requires a version of curl that supports –fail-with-body. In the event of an HTTP error, this option makes the command exit with an error code while keeping the response body available (curl project).

In the request body, model identifies the service and messages contains instructions and text. stream: false requests a complete response. max_tokens limits generation; for this short task we explicitly disable reasoning mode via thinking (DeepSeek).

The text output is found in the first choice, in the message.content field. Before using it, we also check finish_reason: a stop caused by the token limit can leave the content incomplete. The usage field shows how much the request consumed (DeepSeek).

A client-side timeout limits how long the application waits, but it does not prove that the service has stopped all processing. A real integration must also handle the possibility of receiving an error after a request has been accepted.

How to obtain a structured result

For software, it is often useful to receive a JSON object from DeepSeek. The documentation specifies the response_format parameter with type json_object, together with an instruction that explicitly asks for JSON and shows the desired format (DeepSeek).

In our example, we can ask for a request to be classified using these fields:

{
“category”: “support”,
“proposed_priority”: “to_be_verified”,
“missing_data”: [“order number”]
}

The object shows the expected format, not a result obtained from the service. Before passing it to the next process, the application must check that the fields exist, the values belong to the permitted categories and the content is relevant to the original text.

JSON validity concerns syntactic structure. A wrong category or an unsupported priority can sit in an object that the software reads perfectly well. The DeepSeek guide also notes that JSON mode may return empty content: this case must be handled too.

In a first project, it is advisable to keep a confirmation step. The operator sees the request and the proposed classification, corrects it if necessary and records the outcome. Comparing proposals with approved decisions builds a useful sample for evaluating the integration.

DeepSeek API pricing: how to read the costs

DeepSeek API pricing distinguishes between input tokens, output tokens and cache reuse. The current price list also includes peak and off-peak bands. The figures in the table are in dollars per million tokens and were verified on 12 October 2026; for input, we show the rate without cache reuse (DeepSeek).

The peak band given in the documentation runs from 01:00 to 04:00 and from 06:00 to 10:00 UTC, Monday to Friday, with the exceptions set for Chinese public holidays. When planning usage, the time zone must be taken into account and the price list checked again.

Let us try an illustrative calculation: 1,000 requests of 2,000 input tokens and 500 output tokens each. With Flash, without cache, the arithmetic cost would be 0.60 USD off-peak and 1.20 USD at peak. That is 2 million input tokens and half a million output tokens. The simulation excludes additional reasoning tokens, retries, application services and other costs; it is not a forecast of actual consumption.

To read the cost of a project, we can divide total spend by the number of accepted results. If ten requests produce only four usable outputs, the cost of a single call hides part of the problem. Review, development and management must also be factored in.

An integration that costs little per token can take many hours to maintain. The budget must account for who steps in when a model, the response format or a service condition changes.

DeepSeek API errors: how to prepare the process

DeepSeek API errors must produce an outcome that is readable for product users too. The application can keep the draft and inform the operator, rather than replacing a missing response with invented content.

The meanings of the codes come from the official documentation (DeepSeek). The actions should be adapted to your system. A request with an incorrect credential requires a configuration fix; sending it repeatedly adds traffic without resolving the cause.

Retries must be capped. In particular, if the result feeds a submission, a record or another external effect, a repeat must not trigger two actions. We can assign the job an identifier and check in our own system whether the action has already been carried out.

The DeepSeek API and use from Italy

For an Italian project, the DeepSeek APIs also require a check on data processing. On 30 January 2025 the Garante ordered the DeepSeek companies to limit the processing of personal data of data subjects located in Italy in connection with the service (Garante per la protezione dei dati personali).

Before any business use, you need to check any developments in the proceedings and the terms applicable to the chosen service. A technically working connection does not, on its own, prove that the planned processing is permissible. A local deployment of a model and use of the API service hosted by the provider require separate assessments.

The company AI policy must specify which information may be sent to the authorised tool. The technical example in this guide uses invented data; a real project requires the involvement of those who manage privacy, security and authorisations for the process.

A business case: classifying without sending automatically

A first integration with the DeepSeek API can be limited to proposing a classification of messages. Initially we use test texts, explicit categories and an internal destination. The result remains visible to an operator.

Imagine three ordinary categories, delivery, invoicing and support, plus a ‘to be checked’ option. We prepare a sample that includes ambiguous messages, incomplete requests and cases covering several topics. The system must be able to assign a case for checking without being forced to choose one of the three categories.

To assess the work, we compare the proposal with the classification approved by the people responsible. We record errors, correction time and the cases that require intervention. Only after these tests can we decide which further steps to automate.

Human oversight of AI can be designed in at this point: the person sees the original material, understands the proposal and has the power to correct or stop it. A confirmation requested without sufficient information makes oversight less effective.