logo

DeepSeek API Quick Start: Base URL, Models, and First Working Requests

Published
Reviewed

How this article is maintained

This page is maintained by an independent editorial team. We add concise summaries, direct source links when available, and update high-traffic articles when product details change.

Publisher: Qwen-3 Editorial TeamRead editorial policySend corrections

Editorial Summary

A source-based DeepSeek API quick start covering the official base URL, model names, OpenAI compatibility, and what to verify before you build against it.

If you only need one practical fact about the DeepSeek API, it is this:

The official API is OpenAI-compatible, which means many existing SDK and integration patterns transfer with only small configuration changes.

That is the official positioning in DeepSeek's own API docs, and it is the fastest way to reason about how to integrate the service.

The Official Basics

The DeepSeek API docs list these core configuration values:

  • base_url: https://api.deepseek.com
  • compatible alternative base URL: https://api.deepseek.com/v1
  • API key: generated from the DeepSeek platform

The docs also show standard chat-completions usage through:

  • curl
  • Python with the OpenAI SDK
  • Node.js with the OpenAI SDK

Source:

  • DeepSeek API docs: https://api-docs.deepseek.com/

Model Names: What Matters Most

One thing many low-quality guides get wrong is treating product names, web app behavior, and API model names as interchangeable. The official docs are clearer than that.

At the time of the current docs, DeepSeek explicitly documents:

  • deepseek-chat
  • deepseek-reasoner

It also states that these API model names correspond to the current DeepSeek V3.2 generation in the API docs, and that the API versioning is separate from the web/app naming.

That means your safest engineering habit is:

  • check the official docs for currently supported model names
  • do not assume blog posts or third-party screenshots are current
  • keep model names configurable in your app

The Simplest Working Request

The official pattern is a standard chat-completions request:

curl https://api.deepseek.com/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer ${DEEPSEEK_API_KEY}" \ -d '{ "model": "deepseek-chat", "messages": [ {"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "Hello!"} ], "stream": false }'

That is enough to validate:

  • your key works
  • your network path works
  • your chosen SDK wrapper is configured correctly

Do this before you build abstractions on top of the API.

Python and Node.js Patterns

DeepSeek's own docs show using the OpenAI SDK in both Python and Node.js. That is helpful because it lowers migration friction for teams that already support OpenAI-style APIs.

Python

Use the OpenAI client with:

  • api_key
  • base_url="https://api.deepseek.com"

Node.js

Use the OpenAI package with:

  • baseURL: "https://api.deepseek.com"
  • your DeepSeek API key

The practical takeaway is simple:

If your app already has an abstraction for OpenAI-compatible providers, DeepSeek is usually easiest to add as a provider configuration problem rather than a brand-new integration surface.

Common Implementation Mistakes

1. Hard-coding stale model names

Do not freeze model IDs in a tutorial snippet and then forget them. Keep them in environment config or provider settings.

2. Mixing web-app behavior with API behavior

The API docs explicitly separate API model names from app/web product naming. Treat them as different surfaces.

3. Assuming /v1 is a model version

The docs explicitly say the /v1 suffix in the base URL is for compatibility and is not the model version.

4. Skipping a direct curl or SDK smoke test

If you do not validate a minimal request first, you can waste time debugging your own app instead of the actual API configuration.

A Better Production Checklist

Before shipping a DeepSeek integration, verify these:

  1. Provider config Confirm base URL, model name, and key loading are environment-driven.

  2. Timeout and retry policy Set them at your transport layer instead of relying on default SDK behavior.

  3. Streaming behavior Decide whether you need streaming before you design your UI state model.

  4. Output validation Validate structured responses in your app instead of trusting the model to always return the right shape.

  5. Current docs Re-check the official API docs when you deploy or update the integration.

When to Use deepseek-chat vs deepseek-reasoner

The official docs distinguish a non-thinking mode and a thinking mode. In practical terms:

  • use deepseek-chat for standard assistant interaction and general application flows
  • use deepseek-reasoner when you explicitly want a reasoning-oriented behavior and can tolerate a different speed/cost profile

Do not choose by brand impression; choose by task shape and output requirements.

Bottom Line

The best reason to use the DeepSeek API is not that it has its own unique SDK. The best reason is that the official API is deliberately OpenAI-compatible, which lowers integration cost for teams that already have provider abstractions.

If you keep the provider configuration explicit, verify model names from the official docs, and start with a minimal request before building wrappers, the integration path is straightforward.

Sources

  • DeepSeek API docs: https://api-docs.deepseek.com/

Related Articles