How to Create an API Demo Video That Developers Actually Watch

An API demo needs to show both a request and what its response lets someone do. A terminal full of JSON leaves the viewer to work out how the returned data becomes a weather card, a generated document or an action in an application.

Build the demo around one useful result, then show the smallest request and response that explain it. Keep the code readable, highlight the fields as they are discussed and finish with a command the viewer can run.

This guide uses a real weather API request to make that sequence concrete. You can inspect its captured success and error responses, borrow the script structure and see how an existing API product film handles the visual treatment.

Decide which developer question the video should answer

A developer arriving from an API reference needs something different from someone seeing a launch post. The first may already know the endpoint and need to understand its behaviour. The second needs to see a reason to try it.

Choose the question before choosing the effects:

Write the promise as an action. “Get a temperature value and display it with the right unit” is specific enough to demonstrate. “Explore our powerful weather platform” gives you no useful stopping point.

For a broader feature tour, use the product demo planning guide. Keep an API demonstration focused on one call and the application result it produces.

A finished example: showing an API integration as a film

This 3-minute-32-second YourGPT API film walks through SDK integration, responses, tool calls and actions inside an application. The example business, Ledgerly, and its help-document answers are fictional demonstration content.

Watch the API demo MP4 · Download the editable CoAnimator project (.coa, 80 MB).

Open the .coa file in CoAnimator and save a copy before adapting it. The package includes the animation, fonts, narration, music and separate sound-effect tracks. Start with one code-and-response section: replace its example with your approved request, then revise the matching narration and result together.

In the film, a code diff introduces the integration change. A separate view highlights the sources array, then an application scene shows references beside the answer. YourGPT’s API reference documents the knowledgebase tool and returned sources array.

For your API, choose the output you want to show: a generated document, a processed image, a calendar entry or a value appearing in a card. Then identify the call and response fields that produce it.

Capture one real request before you write the narration

Our worked example requests the current temperature for Berlin coordinates from Open-Meteo, then displays the value with its returned unit. Open-Meteo’s documentation explains that these current conditions are model-based, rather than a direct reading from a weather station.

A request for this example looks like this:

curl --silent --show-error --get \
  'https://api.open-meteo.com/v1/forecast' \
  --data-urlencode 'latitude=52.52' \
  --data-urlencode 'longitude=13.41' \
  --data-urlencode 'current=temperature_2m' \
  --data-urlencode 'timezone=UTC' \
  --output weather.json \
  --write-out 'HTTP %{http_code}\n'

The captured request returned HTTP 200. This excerpt preserves the fields used by the demonstration:

{
  "current_units": {
    "time": "iso8601",
    "interval": "seconds",
    "temperature_2m": "°C"
  },
  "current": {
    "time": "2026-11-05T05:15",
    "interval": 900,
    "temperature_2m": 4.3
  }
}

Display 4.3 as 4.3 °C, using the unit returned by the API. Keep the response timestamp beside the value so a saved example is not mistaken for live weather.

The viewer below replays the actual responses captured on 5 November 2026. It does not send another API request. Switch between the valid input and the invalid latitude to see how the application result should change.

Open the response viewer · Download the captured success response · Download the captured error.

Keep the evidence and the presentation together

Save the request, the response body and the HTTP status before editing. Keep the capture date beside them. The animation can then enlarge a field, dim unrelated lines or carry a value into a UI while preserving what the API actually returned.

If you shorten the JSON on screen, label it as an excerpt and keep the full payload available with the written example. Do not silently change a returned value to make a graph prettier or replace a slow result with a made-up response.

For an authenticated API, prepare a dedicated demonstration environment and keep credentials out of the recording. Show an environment-variable name or a visibly masked placeholder in the explanatory code. Inspect the terminal history, headers and surrounding windows before capturing, as well as the line you intend to feature.

Write a short script around the proof

The following is a proposed 60-second cut for the weather example. Adjust the timings if the request or result needs more explanation.

A first line could be: “This card gets its temperature and unit from one request.” The next line names the inputs. Then the result appears. Each sentence has something specific to explain on screen.

Avoid narrating every character as it is typed. “Request temperature for these coordinates” is enough context for a viewer who can read the highlighted parameters. Use the saved time for the point that is easy to miss, such as pairing the value with its returned unit.

Show the completed command before a long typing animation. A developer should be able to pause and understand the call without waiting for decorative keystrokes. Keep an accompanying text version available for copying.

Make the code readable before adding motion

A full editor window usually gives too much space to things the viewer does not need: file trees, tabs, line numbers and unused code. Frame the smallest view that still preserves context. Keep the filename or request method when it helps orientation; remove the surrounding clutter.

In CoAnimator, you can use a real recording or build a typeset code scene from the approved snippet. A typeset scene gives you sharper text and deliberate emphasis, while a recording preserves the actual tool interaction. The choice should be clear in the presentation. An animated reconstruction of a terminal is not evidence that a command ran.

Highlight the parameter being explained, then its corresponding result. Keep the other panels still so the viewer has time to find and read temperature_2m before the next field is introduced.

Judge the result at the size it will be watched. A line that is comfortable on a large editing display may be unreadable inside a documentation page or on a phone. Enlarge the relevant code, reduce the visible line count and use a contrasting background before adding another zoom.

Keep spelling and punctuation faithful to the runnable example. A missing quote, a different variable name or a truncated endpoint can turn a polished frame into a confusing instruction.

Let motion explain the relationship between fields

In the weather example, highlight temperature_2m, then its returned unit. Show where both appear in the weather card and place the timestamp below them. Hold that frame long enough to read all three values.

Use a cut or a short move when attention changes. Hold the frame while the viewer reads. Reserve more expressive transitions for the opening or a chapter change; avoid moving the code continuously while someone is trying to follow its logic.

For sound, give the explanation priority. A quiet music bed can establish rhythm, and a restrained cue can mark the response arriving. Neither should mask the field name, the error or the next action. Review the sequence without sound too: method, status, key result and CTA should remain understandable.

Include one failure that teaches something

For the captured error, the latitude was changed from 52.52 to 100. The API returned HTTP 400 and this body:

{
  "error": true,
  "reason": "Latitude must be in range of -90 to 90°. Given: 100.0."
}

An HTTP 400 response should display an error instead of populating the weather card. Show the corrected latitude and repeat the call before returning to the successful result.

An implementation using browser fetch should inspect the HTTP result explicitly. A response with an error status does not automatically reject the fetch promise; the Fetch guide explains that distinction. In a code scene, show the condition that changes the application behaviour:

const response = await fetch(url);
const data = await response.json();
 
if (!response.ok) {
  throw new Error(data.reason ?? `HTTP ${response.status}`);
}
 
const label = `${data.current.temperature_2m} ${data.current_units.temperature_2m}`;

Here url is the full request URL from the example. A production application also needs appropriate handling for network failures and unexpected response formats. Those can live in the written implementation; the short film can focus on the validation failure that the viewer has just seen.

For a different API, choose a failure that affects the task: an expired token, a missing required field or a job that has not finished yet. Use the service’s actual response and recovery behaviour. Do not add a dramatic retry sequence to an API that does not behave that way.

Give CoAnimator a brief tied to the captured files

Prepare the approved request, the response, the proposed script and any real application capture before asking an agent to assemble scenes. The CoAnimator project format retains the animation and timeline as source files, so a changed endpoint or response can be revised without reconstructing the whole film.

This prompt adapts the weather example into a production brief. It is intended for a project that already contains the named evidence files:

If you need a starting visual treatment, inspect the template catalog before building from a blank canvas. A template supplies composition and timing ideas; the request, payload and product facts still need to come from your evidence.

Review the film as an explanation, then export it

Ask another developer to watch once and answer three questions: what did the request do, which returned fields mattered, and what would they run next? Revise any section they could not explain before adding more effects.

Compare every visible code scene against the saved runnable text. Watch the transition into the error and back out of it. Confirm that a later response has not been paired with an earlier request just because both frames looked better.

Then use CoAnimator’s export controls to choose the delivery settings supported by your licence. Render a short section containing the smallest code before the complete film. Play the exported MP4 in its intended placement, including a phone-sized view.

Keep a written example beside the video. For a repository, a short README demo GIF can link to the full explanation. On a documentation page, place the copyable command and API reference beside the player so viewers can run the request without transcribing code from a frame.

Questions about API demo videos

Make the next step obvious

Finish the demo with the command to run, the expected response and a link to the relevant API reference. Keep the request, captured payload and application example available beside the video.

For a first film, limit the scope to one call. Review the request, result and error frames before assembling the full sequence. If a developer cannot read the code or explain which field populates the result, revise those frames first.

Open a CoAnimator template, supply those files and ask the agent to build the three frames. Use the production prompt above to keep the code, narration and application result consistent as you complete the edit.