Real API calls, real token usage, and real per-request cost for three text-only e-commerce workflows on deepseek-v4-flash.
Choose a model, enter your prompt, and see the result.
HiAPI Blog
HiAPI
Generate it with HiAPI
E-commerce teams don't just need product photos — most of the daily text volume is catalog copy, policy-grounded support replies, and order-status lookups, all of which need to be fast, consistent, and cheap enough to run on every SKU and every ticket.
deepseek-v4-flash, available through the hiapi API, is a text-only open-weight model with no image or video output — if you came here for AI-generated product photography, see the gpt-image-2 e-commerce workflow guide instead. What deepseek-v4-flash is genuinely good at is high-throughput text work at very low cost, backed by a 1M-token context window, native JSON output, and OpenAI-compatible tool calling. This guide covers three concrete e-commerce use cases — batch catalog copy, policy-grounded support replies, and tool-calling order lookups — with real API calls, real token usage, and real per-request cost.
deepseek-v4-flash is the speed- and cost-efficient member of the DeepSeek V4 family: an open-weight mixture-of-experts model with 284B total parameters, 13B active per token, a 1,000,000-token context window, and a 384,000-token maximum output. It's served through hiapi's OpenAI-compatible Chat Completions endpoint only — there's no vision input and no image generation. If your e-commerce workflow needs both photography and copy, hiapi's kimi-k3 e-commerce guide covers a comparable text-only reasoning model; the difference that matters for the use cases below is deepseek-v4-flash's much larger context window and roughly 30-40x lower per-token price (see the cost section).
The model supports two response modes — thinking (default) and non-thinking — controlled by thinking.type, plus a reasoning_effort of high (default) or max while thinking is enabled. In our own testing, setting thinking.type: "disabled" still produced a small amount of reasoning_content and non-zero reasoning_tokens rather than eliminating them outright — worth knowing before you assume "disabled" means zero reasoning cost. The measured costs below already account for this.
Instead of one API call per SKU, dump a batch of raw specs into a single request and ask for structured JSON back. This is where the 1M-token context matters: a few hundred SKUs' worth of spec sheets fit comfortably in one call, and response_format: {"type": "json_object"} gets you machine-parseable output your catalog pipeline can ingest directly, no regex-scraping a chat response.
curl https://api.hiapi.ai/v1/chat/completions \
-H "Authorization: Bearer $HIAPI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek-v4-flash",
"messages": [
{
"role": "system",
"content": "You are an e-commerce catalog copywriter. Given a list of raw product specs, return a JSON object with key \"products\", an array where each item has: sku, title (max 70 chars), bullets (3 strings), meta_description (max 155 chars). Output JSON only."
},
{
"role": "user",
"content": "Write catalog copy for these 3 SKUs.\n\nSKU MW-201: Men'\''s running shoe, mesh upper, breathable, 280g weight, EVA midsole, rubber outsole, sizes 7-13, colors: black/red, black/white, navy.\n\nSKU KB-114: Stainless steel kitchen knife set, 6 pieces, high-carbon steel blades, ergonomic handles, includes wooden block, dishwasher safe blades only.\n\nSKU LP-330: USB-C laptop charger, 65W fast charging, compatible with most USB-C laptops and phones, 1.8m braided cable, compact foldable plug."
}
],
"thinking": {"type": "disabled"},
"response_format": {"type": "json_object"}
}'
The real response for those 3 SKUs:
{
"products": [
{
"sku": "MW-201",
"title": "Men's Running Shoe - Breathable Mesh, EVA Midsole",
"bullets": [
"Breathable mesh upper keeps feet cool and dry during runs",
"Lightweight 280g design with EVA midsole for responsive cushioning",
"Durable rubber outsole with multiple color options, sizes 7-13"
],
"meta_description": "Shop MW-201 men's running shoe: breathable mesh, EVA midsole, rubber outsole. Lightweight 280g, sizes 7-13 in black/red, black/white, navy."
}
]
}
Actual usage for this call: 277 prompt tokens, 962 completion tokens (555 of them reasoning tokens, even with thinking disabled), 1,239 total. At $0.14/M input and $0.28/M output, that's $0.00031 for three fully-written SKU listings — and the same request shape scales to a few hundred SKUs per call before you approach the context limit, not per-SKU round trips.
Support replies fail when a model paraphrases a policy it doesn't actually have — it either invents an exception or misses one. With a 1M-token window you can paste your entire return/warranty/shipping policy into the system prompt on every request instead of retrieving and truncating snippets, so the model reasons over the actual document rather than a fragment.
curl https://api.hiapi.ai/v1/chat/completions \
-H "Authorization: Bearer $HIAPI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek-v4-flash",
"messages": [
{
"role": "system",
"content": "You are a customer support agent for Northwind Outdoor Gear. Answer strictly based on the policy document provided. Cite which policy section applies. If the customer is not eligible for what they asked, say so clearly and explain what they ARE eligible for instead."
},
{
"role": "user",
"content": "POLICY DOCUMENT:\n<full return/warranty policy text>\n\nCUSTOMER MESSAGE:\nHi, I bought hiking boots 7 weeks ago and wore them on two trail hikes. Now the sole is separating from the left boot. I do not have the original box anymore. Can I get a refund, and do I need to pay for return shipping?"
}
],
"thinking": {"type": "enabled"},
"reasoning_effort": "high"
}'
Fed a real 6-section return/warranty policy document, the model correctly distinguished the standard 30-day return policy (which doesn't apply — the boots were worn) from the 12-month manufacturing-defect warranty (which does apply — sole separation is explicitly listed), correctly noted the original box isn't required for a warranty claim even though it is for a standard return, and correctly waived return shipping for a defect claim. That's four separate policy details applied correctly against a single 6-section document pasted directly into the request.
Actual usage: 552 prompt tokens, 730 completion tokens (417 reasoning), 1,282 total — $0.00028 per reply with full policy grounding and reasoning_effort: high.
For "where's my order" tickets, you don't want the model guessing — you want it to call your order-status API and answer from the real result. deepseek-v4-flash supports OpenAI-compatible tools with tool_choice: "auto" (the compatible default in thinking mode; some forced tool_choice values aren't supported while thinking is enabled).
curl https://api.hiapi.ai/v1/chat/completions \
-H "Authorization: Bearer $HIAPI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek-v4-flash",
"messages": [
{"role": "system", "content": "You are an order-status assistant. Use the get_order_status tool to look up orders before answering."},
{"role": "user", "content": "Where is my order #A-88213?"}
],
"tools": [{
"type": "function",
"function": {
"name": "get_order_status",
"description": "Look up the current shipping status of a customer order by order ID.",
"parameters": {
"type": "object",
"properties": {"order_id": {"type": "string", "description": "The order ID, e.g. A-88213"}},
"required": ["order_id"]
}
}
}],
"tool_choice": "auto",
"thinking": {"type": "enabled"},
"reasoning_effort": "high"
}'
The model correctly extracted the order ID and issued a real tool call — get_order_status({"order_id": "A-88213"}) — instead of answering from a guess. Run your own lookup, feed the result back as a tool message, and let the model draft the final reply. This call used 411 prompt tokens and 75 completion tokens (25 reasoning) — $0.00008 just for the routing step.
Running the exact same token counts through kimi-k3's pricing ($2.32/M input, $11.60/M output) instead of deepseek-v4-flash's ($0.14/M input, $0.28/M output):
| Call | deepseek-v4-flash | Same tokens on kimi-k3 | Ratio |
|---|---|---|---|
| Catalog copy (3 SKUs, JSON mode) | $0.00031 | $0.0118 | ~38x |
| Policy-grounded support reply | $0.00028 | $0.0097 | ~35x |
At 50,000 support tickets and 20,000 catalog SKU refreshes a month, that's the difference between roughly $20/month and $700+/month for the same workload — before you even account for deepseek-v4-flash's larger context letting you batch more work per call in the first place. See the full pricing table for every model hiapi hosts side by side.
You need a hiapi API key (same key works across every model on the platform) and a POST to the Chat Completions endpoint:
curl https://api.hiapi.ai/v1/chat/completions \
-H "Authorization: Bearer $HIAPI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek-v4-flash",
"messages": [{"role": "user", "content": "Return JSON with keys summary and risks."}],
"thinking": {"type": "disabled"},
"response_format": {"type": "json_object"}
}'
For streaming responses, migrating an existing OpenAI SDK client, and the full parameter reference (max_tokens, stream, thinking, reasoning_effort, response_format, tools), see the deepseek-v4-flash docs and the general API tutorial for curl and Python setup. Check the rate limits before you wire up bulk catalog runs. Read the answer from choices[0].message.content; in thinking mode, the reasoning trace is in choices[0].message.reasoning_content — preserve it in the assistant message if you continue a tool-call turn.
Does deepseek-v4-flash generate product images? No — it's text-only. Pair it with a dedicated image model like the one covered in the gpt-image-2 e-commerce guide if you need product photography in the same pipeline.
Does disabling thinking guarantee zero reasoning cost? Not in our testing — thinking.type: "disabled" still produced non-zero reasoning_tokens and a short reasoning_content field on every call we made, including a one-word response. Budget from measured usage, not from the parameter name alone.
How big a catalog or policy doc can I actually paste in? Up to the 1,000,000-token context window, with up to 384,000 tokens of output — big enough for a full multi-page policy document or a batch of a few hundred SKU spec sheets in one request, well beyond what fits in most models' context.