You want users to message your business on WhatsApp and get answers from a model you actually trust — not a brittle keyword tree. This guide walks through a working DeepSeek WhatsApp integration end to end: a Python webhook receiver that listens to Meta’s WhatsApp Cloud API, forwards each message to `deepseek-v4-flash`, and replies back inside the 24-hour conversation window. By the end you’ll have a deployed bot, a cost model that survives audit, and a clear migration path off the legacy `deepseek-chat` ID before it retires. Code is in Python with FastAPI; the same pattern works in Node.js. Expect about an afternoon of work to reach a live test number.

What you’ll build

The architecture is three moving parts: WhatsApp Cloud API on Meta’s side, a public HTTPS webhook on your side, and DeepSeek’s POST /chat/completions endpoint for inference. When a user messages your business number, Meta posts a JSON payload to your webhook; your handler extracts the text, calls DeepSeek, and posts the reply back through Meta’s Graph API. DeepSeek V4-Flash is the right tier here — it costs $0.14 per million input tokens on a cache miss and $0.28 per million output, which keeps per-conversation cost in fractions of a cent.

A note on the model choice. DeepSeek-V4-Pro carries 1.6T total / 49B active parameters and rivals top closed-source models, while DeepSeek-V4-Flash is the 284B total / 13B active “fast, efficient, and economical choice”. For chat-style customer messages, Flash is plenty. Reserve Pro for agentic coding or research workflows where the benchmark lift is worth the roughly 7x cost gap on output.

Prerequisites

• A Meta Business account (Business Manager) with admin access
• A Meta for Developers account and a new app with the WhatsApp product added
• A phone number that can receive SMS or voice for verification — a fresh number is easiest
• A public HTTPS endpoint for the webhook (ngrok works for testing; Cloud Run, Fly.io, or AWS Lambda for production)
• A DeepSeek API key — see how to get a DeepSeek API key
• Python 3.11+ with fastapi, uvicorn, httpx, and the openai SDK

Meta’s prerequisite list maps cleanly: a Business Manager admin account, a Meta Developer account, a phone number that can receive SMS or voice for verification, a public HTTPS endpoint for webhooks, and a basic server (Node, PHP, or in our case Python) to store tokens and call the Graph API.

Step 1: Create the Meta app and connect WhatsApp

In Meta for Developers, create a new Business-type app and add the WhatsApp product. In the API Setup section, connect the app to a WhatsApp Business Account — either select an existing one or create a new one — and save the WhatsApp Business Account ID for use in API calls. From the same panel, copy the test phone number ID and the temporary access token.

The temporary token is fine for the next ten minutes of testing. For anything beyond that, follow Meta’s instructions to create a System User and a permanent access token; otherwise your bot will silently break the next day.

Step 2: Stand up a webhook receiver

The webhook has two jobs. On GET, it answers Meta’s verification handshake by echoing back the hub.challenge parameter. On POST, it receives inbound messages and acknowledges them within five seconds. Your server must respond with a 200 OK within 5 seconds for Meta to consider the webhook processed; if you fail 5 consecutive times, Meta will temporarily disable the webhook, so push the DeepSeek call to a background task.

Save the following as main.py. It uses FastAPI plus a background task so the HTTP response is immediate.

import os
import httpx
from fastapi import FastAPI, Request, BackgroundTasks, HTTPException
from openai import OpenAI

VERIFY_TOKEN = os.environ["WA_VERIFY_TOKEN"]
WA_TOKEN     = os.environ["WA_ACCESS_TOKEN"]
PHONE_ID     = os.environ["WA_PHONE_NUMBER_ID"]
GRAPH_URL    = f"https://graph.facebook.com/v22.0/{PHONE_ID}/messages"

deepseek = OpenAI(
    base_url="https://api.deepseek.com",
    api_key=os.environ["DEEPSEEK_API_KEY"],
)

app = FastAPI()

@app.get("/webhook")
async def verify(request: Request):
    params = request.query_params
    if (params.get("hub.mode") == "subscribe"
            and params.get("hub.verify_token") == VERIFY_TOKEN):
        return int(params["hub.challenge"])
    raise HTTPException(status_code=403)

@app.post("/webhook")
async def receive(request: Request, background: BackgroundTasks):
    payload = await request.json()
    try:
        msg = payload["entry"][0]["changes"][0]["value"]["messages"][0]
        if msg.get("type") == "text":
            background.add_task(handle_message, msg["from"], msg["text"]["body"])
    except (KeyError, IndexError):
        pass  # status callbacks and other event shapes
    return {"status": "ok"}

The verification branch matches the pattern in Meta’s own developer docs: the endpoint is very simple — it returns the hub.challenge parameter, which the verification system sends as a request parameter. The POST branch tolerates non-text payloads (status receipts, reactions, media) without crashing.

Step 3: Wire DeepSeek into the message handler

Chat requests hit POST /chat/completions, the OpenAI-compatible endpoint at https://api.deepseek.com. The OpenAI Python SDK works unchanged — only base_url and api_key change. Critically, the API is stateless: DeepSeek does not remember prior turns on its side, so for multi-turn chat you must resend the conversation history with each request. The web chat at chat.deepseek.com keeps session history; the API does not. Plan for a small per-user message store (Redis, DynamoDB, Postgres) if you need memory.

For this minimal bot, we’ll keep a tiny in-memory store. Replace with a real database before production.

HISTORY: dict[str, list[dict]] = {}

SYSTEM_PROMPT = (
    "You are a concise WhatsApp assistant for ACME Coffee. "
    "Answer in under 60 words. If you do not know, say so."
)

async def handle_message(wa_from: str, text: str):
    history = HISTORY.setdefault(wa_from, [{"role": "system", "content": SYSTEM_PROMPT}])
    history.append({"role": "user", "content": text})

    resp = deepseek.chat.completions.create(
        model="deepseek-v4-flash",
        messages=history,
        temperature=1.3,        # general conversation
        max_tokens=400,
    )
    reply = resp.choices[0].message.content
    history.append({"role": "assistant", "content": reply})
    HISTORY[wa_from] = history[-20:]  # keep last 10 turns

    async with httpx.AsyncClient(timeout=15) as client:
        await client.post(
            GRAPH_URL,
            headers={"Authorization": f"Bearer {WA_TOKEN}"},
            json={
                "messaging_product": "whatsapp",
                "to": wa_from,
                "type": "text",
                "text": {"body": reply},
            },
        )

Three parameter choices to flag. temperature=1.3 matches DeepSeek’s official guidance for general conversation and translation. max_tokens=400 caps reply length; WhatsApp’s reading experience falls apart past a few short paragraphs. model="deepseek-v4-flash" targets the cost-efficient tier directly. If you want thinking mode for harder questions, swap to reasoning_effort="high" with extra_body={"thinking": {"type": "enabled"}}; the response will then contain reasoning_content alongside the final content, and you should send only the latter back to WhatsApp.

Step 4: Expose the webhook and subscribe in Meta

For local testing, run uvicorn main:app --port 8000 and tunnel through ngrok. In production, deploy behind HTTPS on whatever you already use. In the Meta App Dashboard, go to WhatsApp → Configuration, paste the public URL plus your verify token, and subscribe to the messages field. Meta’s documentation on creating a webhook endpoint confirms this is the right surface to register.

Step 5: Send a test message

From the API Setup panel in Meta, send the hello_world template to your own WhatsApp number. Reply to that thread with any text. The webhook should fire, your handler should call DeepSeek, and the reply should appear within a few seconds. Once your test webhook application is established, respond in the WhatsApp chat thread you created with yourself, then check your test webhook to view the event confirming the message receipt.

Verify it worked

• Server logs show a 200 response on the POST and the parsed message body
• DeepSeek’s billing console shows tokens consumed for deepseek-v4-flash
• The user receives a coherent reply on WhatsApp within ~3 seconds
• A second message in the same thread references the first (proving history is being resent)

Cost math: a worked example for V4-Flash

Pricing as of April 2026 from DeepSeek’s own pricing page: $0.028 per million input tokens on a cache hit, $0.14 per million on a cache miss, $0.28 per million output tokens. DeepSeek charges $0.14/million tokens input and $0.28/million tokens output for Flash, and $1.74/million input and $3.48/million output for Pro. Off-peak discounts ended on 2025-09-05 and have not returned with V4.

Imagine a busy support line: 100,000 conversations a month, average 6 turns each, 100-token user messages, 200-token replies, with a stable 300-token system prompt that stays cached after the first call.

Under sixty dollars for 600,000 model calls. WhatsApp’s per-conversation fees from Meta will dwarf the inference bill at that volume, not the other way around. For a deeper walkthrough of the rate card, see the breakdown of DeepSeek API pricing and the DeepSeek context caching guide. Do not skip the cache-miss line — every new user message is a miss against the cached prefix until the model sees it again. Don’t mix V4-Flash and V4-Pro rates in one calculation; pick a tier and stay in it.

Migrating off legacy model IDs

If you copy-pasted code from a 2025 tutorial, you probably have model="deepseek-chat" or model="deepseek-reasoner" in there. Both still work, but deepseek-chat and deepseek-reasoner will be fully retired and inaccessible after July 24, 2026, 15:59 UTC, currently routing to deepseek-v4-flash non-thinking and thinking respectively. The migration is a one-line change to model="deepseek-v4-flash" — base_url stays the same. Test it before the cutoff, not the morning of.

Common errors and fixes

One more behavioural quirk to internalise: V4’s context window is 1,000,000 tokens by default with output up to 384,000 tokens. You will not hit either limit on a WhatsApp bot, but the headroom means you can stash long policy documents in the system prompt and trust the cache pricing to keep costs sane.

Hardening for production

• Persist history. Replace the in-memory HISTORY dict with Redis keyed by wa_id. Cap stored turns to keep per-user prompts bounded.
• Verify Meta signatures. Validate the X-Hub-Signature-256 header on every POST; reject anything that doesn’t match.
• Add a fallback. If DeepSeek returns a 5xx, send a polite “I’m having trouble — try again in a moment” instead of silence.
• Respect opt-in. Store consent timestamp and source per user; WhatsApp’s Business Messaging Policy is enforced on quality, not just volume.
• Rate-limit per wa_id. One inbound burst from a single user shouldn’t fan out to 200 DeepSeek calls.

Next steps

Two natural extensions. First, make the bot multi-modal: receive WhatsApp voice notes, transcribe them, then process the text through DeepSeek. Second, add tool calling so the bot can look up an order status against your real backend rather than guessing. The same FastAPI handler is the foundation for both. If you’d rather build on a chat-platform that’s friendlier for early prototyping, the DeepSeek Telegram bot tutorial covers a near-identical pattern with a much lighter onboarding flow, and the DeepSeek Discord bot guide shows how to run the same handler against Discord’s Gateway. For the broader catalogue of integrations, the DeepSeek tutorials hub indexes every step-by-step on the site.

One reference for primary sources before you ship: DeepSeek’s official V4 Preview release notes document the model IDs, the dual-mode behaviour, and the legacy retirement date in DeepSeek’s own words. Bookmark it.

Last verified: 2026-04-25. DeepSeek AI Guide is an independent resource and is not affiliated with DeepSeek or its parent company. Model IDs, pricing and API behaviour change; check the official DeepSeek documentation and pricing page before committing to a production decision.