D-ID API uses Basic auth; Sume uses a bearer API key

D-ID's getting-started reference says an API key is generated in the studio account settings and that requests carry an Authorization header using Basic authentication with the API credentials. Sume uses Authorization: Bearer $SUME_API_KEY, with the key read from an environment variable. If you are porting a D-ID integration, the header line is the first diff; the second is that Sume answers with a job you poll, or a webhook, instead of a talk resource.

D-ID source: Get started, read 2026-10-04. Sume source: Authentication.

The header diff

The shape of the two calls is similar enough that a thin wrapper can hide the difference. Keep the secret out of source control and read it from the environment in both cases.

A tiny client

One function owns authentication so the rest of your code never touches the header.

import os
import requests

def sume(method, path, **kw):
    key = os.environ["SUME_API_KEY"]
    headers = {"Authorization": f"Bearer {key}", **kw.pop("headers", {})}
    return requests.request(method, f"https://api.sume.com{path}", headers=headers, timeout=30, **kw)

print(sume("GET", "/v1/avatar-1.0/avatars").status_code)

Other things that move

D-ID lists several product lines in its overview, from realtime agents to video translate. Sume's avatar flow is two steps: create a reusable avatar, then render a talking video. Map each D-ID call you use to one of those, and note that Sume's media URLs are durable media.sume.com artifacts.

• Replace the auth header in one place.
• Store the job id you get back, not a talk id.
• Add an Idempotency-Key to every create call.
• Test in a non-production workspace first.

Bottom line

Authentication is the smallest part of a migration. Read the jobs guide for how results arrive, and plan the polling or webhook change at the same time as the header change.