HeyGen API key permissions: /v3/api_keys/self vs Sume /v1/me

To see what a HeyGen key can do, call GET /v3/api_keys/self: the September 2026 changelog says it returns the name, scope_mode, scopes and expiration of the key making the request. Sume's equivalent single call is GET /v1/me, which verifies the key and returns non-secret account and key metadata for the resolved workspace.

HeyGen facts are from its changelog; Sume facts are from Authentication and Public API, read 2026-09-30.

What does each endpoint tell me?

Both answer "is this key valid and what is it". The Sume docs describe the response only as non-secret account and key metadata, so do not build logic on scope fields the docs do not list.

How do I call /v1/me?

Send the key as a Bearer token or as x-api-key. Both are accepted, but send exactly one: a request carrying both is rejected with 401 unauthorized.

curl https://api.sume.com/v1/me \
  -H "Authorization: Bearer $SUME_API_KEY"

When should I run the check?

The rotation guidance is to create a replacement key, deploy it to your server, verify GET /v1/me, then revoke the old key from the dashboard. The same call works as a health step in a deploy script. More on key handling in Sume API keys, scopes and hosts.

Does Sume list scopes or expiry like HeyGen?

The docs quoted here do not say so for /v1/me. If you need expiry or scope detail, read the key's page in the dashboard or the OpenAPI schema for the response, rather than relying on this post.