How to Use the DeepSeek API for Builder Workflows
Editorial standards and source policy: Editorial standards, Team. Content links to primary sources; see Methodology.
The safest way to use DeepSeek is to treat it as an API workflow, not a generic chatbot trick. Start from the official DeepSeek docs, confirm current model names and pricing, run one non-production task, and keep a fallback provider until the workflow has survived real review. This avoids the usual tutorial problem: copying an access path without knowing whether it fits your product, budget, or reliability requirements.
Quick Decision
| Step | Builder action | Stop if |
|---|---|---|
| Access | Open official DeepSeek API docs and confirm model names, keys, limits, and pricing | The provider page does not match the tutorial being followed. |
| First task | Run one non-production prompt set with expected output and budget | The output cannot be checked by a human reviewer. |
| Cost check | Calculate input, output, cache, and retry costs | The apparent saving disappears after retries or repair work. |
| Integration | Add only one workflow behind a fallback | The app depends on one model with no rollback route. |
Current Official Snapshot
Last checked: 2026-07-09. Use DeepSeek API docs and DeepSeek pricing before copying code. The official pricing page currently lists deepseek-v4-flash and deepseek-v4-pro, names https://api.deepseek.com as the OpenAI-format base URL, and says pricing is measured per 1M input and output tokens. It also notes that legacy model names deepseek-chat and deepseek-reasoner are scheduled for deprecation on 2026-07-24 15:59 UTC and correspond to non-thinking and thinking modes of deepseek-v4-flash for compatibility.
That deprecation note matters more than a generic tutorial. If an older guide tells you to use deepseek-chat, do not copy it into a new integration without checking the current pricing page. Use the current model names for new tests, keep the alias behavior only as a compatibility fact, and write the model name into your run log.
| Official item | Current snapshot | Builder implication |
|---|---|---|
| Base URL | DeepSeek API host shown in the official docs for OpenAI-format calls | Existing OpenAI-style clients may be adaptable, but still need model and error handling checks. |
| Current model names | deepseek-v4-flash and deepseek-v4-pro | Use current names in new tests instead of copying stale aliases. |
| Legacy aliases | deepseek-chat and deepseek-reasoner deprecation scheduled for 2026-07-24 15:59 UTC | Audit tutorials, examples, and environment variables before launch. |
| Pricing unit | Per 1M input/output tokens, with cache-hit/cache-miss distinctions on the official page | Measure cost per accepted result, not just cost per call. |
Minimal API Call
This is a minimal shape for a non-production check. Set DEEPSEEK_BASE_URL from the official DeepSeek docs before copying it, keep the API key out of source control, and log the exact model name used.
curl "$DEEPSEEK_BASE_URL/chat/completions" \
-H "Authorization: Bearer $DEEPSEEK_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek-v4-pro",
"messages": [
{"role": "system", "content": "Return concise JSON."},
{"role": "user", "content": "Classify this support ticket as billing, bug, or product question: ..."}
]
}'
The call itself is not the integration. The integration starts when you define the expected output, retry budget, logging, fallback model, and human review rule. If the response cannot be checked by a person or an automated test, it is too early to route production traffic.
Support-ticket Classifier Example
Start with 200 historical support tickets that already have human labels: billing, bug, product question, account access, or security. Send only the subject and redacted body to DeepSeek. Ask for JSON with label, confidence, and reason. Compare against the known label and inspect disagreements.
This is a better first task than an open-ended chatbot because it has a measurable acceptance test. You can calculate accepted results, retries, parsing failures, and human repair time. If DeepSeek is cheaper per call but produces unparseable JSON or low-confidence labels, the cost advantage disappears.
RAG Routing Example
For a RAG workflow, do not ask DeepSeek to answer everything. Ask it to decide whether a user question should route to policy docs, API docs, pricing docs, or human support. The output should include the selected collection and a short reason. This keeps the model's role narrow and makes failures easy to inspect.
Fallback and Rollback
Keep the current provider as a fallback during the first integration. Route a small percentage of traffic, log failures, and define the condition that sends the workflow back to the baseline. Do not let a new model become a hidden dependency before the team understands its failure modes.
Source Checklist
FAQ
Can I start with a third-party DeepSeek tutorial?
Use tutorials only after checking the official DeepSeek docs for current model names, pricing, and access details.
What is a good first DeepSeek API task?
Use a task with known inputs and checkable outputs, such as classification, summarization, or code explanation.
How should I compare cost?
Compare cost per accepted result, including retries and human repair time.
Do I need a fallback?
Yes. Keep a baseline provider until the DeepSeek workflow survives production-like review.