FIELD GUIDE

D-ID Talking Photos: API Request Design, Source Consent and Result Handling

Version: Talks API | Documented or relevant tier: API billing and plan unresolved | Verification date: 2026-10-25 | Coverage cut-off: 2026-10-25 | Editorial status: REVIEW — open verification issues remain

D-ID’s Talks API demonstrates an avatar-production pathway in which an image is animated using a script. Unlike prompt-to-cinematic-video tools, this work is usually closer to a synthetic talking-head asset: a photograph or approved studio actor becomes the visible presenter, while text or audio drives the spoken content.

What the API reference establishes

The official Create a Talk reference documents `POST https://api.d-id.com/talks`. Its request accepts a `source_url` pointing to an image such as JPEG or PNG, a required `script` structure and optional configuration and webhook values. It also documents text-script and audio-script alternatives and response error categories including moderation and insufficient credits. This is specific to a talks asset, not the same API surface as the provider’s agent streaming framework.

An implementation should not expose API keys in a webpage or include a user’s unapproved private portrait in a public sample repository. Put credentials server-side, use securely controlled source URLs and retain only the minimum sensitive data necessary for the job. Validate an uploaded image’s rights and person consent before handing it to any remote avatar system.

Build a safe asynchronous job

Create an internal job ID, store the consent record, collect the source image and prepare a short script. Submit the request with a callback endpoint if that is how your selected API version reports results; authenticate the callback, associate it with the original job and download the resulting media promptly. Handle `402` insufficient-credit responses differently from moderation `451` responses or recoverable network errors. Retry carefully to avoid duplicate billable jobs.

Proofread the script, particularly proper names, regulatory language and numbers, before synthesis. If an audio script is used, ensure you possess rights to that recording and the speaker’s synthetic representation. Check the finished talk for mismatched phonemes, face warping and awkward pauses. Add captions and any needed synthetic-media disclosure in the final editor.

Do not confuse streaming generations

D-ID’s documentation also marks legacy Talks Streams APIs as deprecated and directs developers to newer Agents equivalents. An old WebRTC streaming tutorial should not be mixed with a create-and-download Talks endpoint. Record which interface is used, whether the video is generated in batch or as a stream, the output’s resolution and retention once these are verified for a specific plan.

Because current region, tier, duration and exact video costs were not verified from a plan-specific first-party rate card in this pass, those matrix fields remain null. The verified article is about the API’s operation and the production safeguards, not a price guarantee.

Worked production example

A museum wants an animated portrait to introduce an exhibit. Use a fictional or specifically consented subject, host the source photo securely and send a short, approved script through the correct Talks endpoint. Handle callback responses and media download without exposing the API credential in a visitor-facing page. Review mouth movement and factual phrasing before displaying it. If the museum later wants a real-time conversational guide, treat that as a distinct agent-streaming project with its own network, privacy and moderation review rather than stretching the prerecorded talk API beyond its design.

Relevant alternatives and trade-offs

For an approved recurring presenter, compare Synthesia or HeyGen avatar governance; for expressive cinema, a talking-photo endpoint is the wrong tool.

Sources & Further Reading

CONTINUE EXPLORINGExplore related files ↗