Crear un token Bearer

Intercambia las credenciales de la Auth Key por un token de portador con ámbito restringido.

Este es el endpoint de tokens OAuth 2.0. Los clientes sin interfaz gráfica intercambian su Auth Key y su Auth Secret por un token Bearer de corta duración mediante la concesión client_credentials, gestionada directamente por la API de Transloadit. Los clientes MCP que se conectaron mediante URL canjean el código de autorización de la pantalla de consentimiento de la consola mediante la concesión authorization_code (PKCE S256, sin credenciales HTTP Basic) y rotan el token de actualización resultante mediante la concesión refresh_token.

En /token, los errores de las concesiones OAuth para authorization_code y refresh_token usan el cuerpo estándar con error y error_description. Los límites de frecuencia devuelven RATE_LIMIT_REACHED (429), y los fallos internos inesperados devuelven SERVER_500 (500). Las solicitudes mal formadas que se rechazan antes de identificar la concesión pueden recibir un desafío HTTP Basic (401), o TOKEN_INVALID_REQUEST si se proporcionaron credenciales Basic.

Los tokens de credenciales de cliente se generan en el servidor mediante tu Auth Key y tu Auth Secret. Si expones la creación de tokens a través de una interfaz de usuario, llama a /token desde tu backend (nunca directamente desde el navegador).

Los Workspaces cancelados no pueden crear nuevos tokens Bearer. Para los endpoints cuya documentación permita explícitamente lecturas tras la cancelación, usa en su lugar la guía de lectura firmada con una Auth Key activa existente. La facturación tiene su propia guía de facturación firmada.

Las solicitudes deben usar application/x-www-form-urlencoded; la concesión client_credentials también requiere autenticación HTTP Basic:

En una shell de confianza del lado del servidor con curl y jq, asigna a TRANSLOADIT_KEY y TRANSLOADIT_SECRET los valores de tu Auth Key y tu Auth Secret. Mantén en secreto ambas credenciales y el token resultante; nunca ejecutes esta configuración en código del navegador.

Este ejemplo solicita acceso de lectura/escritura a las Assemblies y guarda el access_token devuelto como TRANSLOADIT_TOKEN para las solicitudes posteriores en la misma shell. Para otro endpoint, usa en su lugar los ámbitos que se indican para él; la Auth Key ya debe concederlos. Los endpoints autenticados mediante una Auth Key o un token Bearer incluyen la configuración de token adecuada en sus ejemplos de solicitud.

if ! TOKEN_RESPONSE="$(curl --fail-with-body -sS \
  --request POST \
  --url 'https://api2.transloadit.com/token' \
  --user "${TRANSLOADIT_KEY:?Set TRANSLOADIT_KEY}:${TRANSLOADIT_SECRET:?Set TRANSLOADIT_SECRET}" \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'grant_type=client_credentials' \
  --data-urlencode 'aud=api2' \
  --data-urlencode 'scope=assemblies:read assemblies:write')"; then
  printf '%s\n' "$TOKEN_RESPONSE" >&2
  exit 1
fi
TRANSLOADIT_TOKEN="$(printf '%s' "$TOKEN_RESPONSE" |
  jq -er '.access_token | strings | select(length > 0)')" || exit 1

Se requiere autenticación básica HTTP con tu Auth Key y tu Auth Secret para los siguientes valores de grant_type: client_credentials. Los demás valores admitidos no necesitan credenciales de la cuenta. No envíes una cabecera Authorization en esas solicitudes; la prueba específica de su concesión sigue siendo obligatoria.

Tipo de contenido: application/x-www-form-urlencoded

Los siguientes campos pueden enviarse como máximo una vez: aud, client_assertion, client_assertion_type, client_id, code, code_verifier, grant_type, redirect_uri, refresh_token, resource, scope.

Uso del token

Pasa el token como Authorization: Bearer <access_token> en las solicitudes a la API. Cuando una solicitud se autentica con un token Bearer válido, API2 considera satisfecho el requisito de Signature Authentication y omite la validación de la Signature. Signature Authentication solo se exige para las solicitudes con clave/secreto. Las comprobaciones de ámbito siguen aplicándose. La audiencia predeterminada api2 se acepta en los endpoints habituales de API2 y es válida durante 21.600 segundos de forma predeterminada. La audiencia mcp se acepta en el servidor MCP, que la transmite a API2 con una credencial de servicio; los endpoints habituales de API2 la rechazan cuando se presenta directamente, y es válida durante 604.800 segundos de forma predeterminada. Toma como definitivo el valor expires_in de la respuesta.