Autenticação

Auth Keys

Para solicitações multipart de criação de Assembly autenticadas com uma Auth Key, inclua um objeto auth dentro do campo de formulário params codificado em JSON. O menor valor de params para esse caso é mostrado abaixo.

{
  "auth": {
    "key": "23c96d084c744219a2ce156772ec3211"
  }
}

O campo key se refere à Auth Key associada ao seu Workspace da Transloadit, encontrada na página Credenciais. O exemplo acima é o objeto mínimo de autenticação para uma solicitação de Assembly que usa uma Auth Key. Outros endpoints e métodos de autenticação podem usar formatos de solicitação diferentes, conforme descrito na documentação de cada endpoint e abaixo.

As Assemblies que usam /transloadit/import, diretamente ou por meio de um Template, exigem um token bearer ou params assinado com um timestamp futuro em params.auth.expires. Isso se aplica mesmo quando a Signature Authentication do Workspace está desativada. Uma Auth Key sozinha não é suficiente; solicitações autenticadas com bearer não precisam de assinatura nem de expiração separadas. Os Builtin Templates públicos de Storage são a exceção: eles podem atender a solicitações sem assinatura somente quando todas as importações de Storage permanecem dentro de um prefixo declarado como público. Isso não autoriza Assemblies sem assinatura com Steps arbitrários nem acesso a caminhos privados de Storage.

Signature Authentication

Recomendamos ativar a Signature Authentication na sua conta, especialmente se você estiver integrando a Transloadit a partir de um ambiente não confiável (como o navegador com Uppy⁠). Você pode ativar a Signature Authentication nas Configurações do Workspace.

Com a Signature Authentication ativada, o Auth Secret do seu Workspace (encontrado ao lado da sua Auth Key na página Credenciais) é usado como chave para um HMAC gerado a partir dos bytes exatos do valor serializado de params. Esse valor contém tanto uma key (que é sua Auth Key, como mencionado anteriormente) quanto um parâmetro expires, que é um timestamp em um futuro próximo usado como data de expiração da solicitação.

Para criar Assemblies com a Transloadit, seu back-end poderia calcular uma assinatura que abranja apenas determinados parâmetros, usuários autenticados e um intervalo de tempo que considere um uso legítimo. Por exemplo, ele se recusaria a gerar uma assinatura para usuários que não estejam conectados. Você poderia usar qualquer lógica de negócio no servidor para decidir se fornece uma assinatura ou não. A Transloadit pode exigir uma assinatura correta para o payload quando uma solicitação à API é autenticada com sua Auth Key.

Para exigir Signature Authentication em solicitações à API autenticadas com sua Auth Key:

1. Acesse as Configurações do Workspace na sua conta.
2. Na seção Configurações da API, ative a opção Exigir uma assinatura correta.
3. Aguarde a conclusão do salvamento automático.

Tokens bearer válidos dispensam os requisitos de assinatura, incluindo as configurações do Workspace e do Template; os escopos do token e as restrições de público-alvo continuam se aplicando. Essas configurações não adicionam autenticação ao acesso baseado em URLs que conferem acesso, como URLs de status de Assembly, cancelamento ou upload retomável. Mantenha os Assembly IDs e as URLs que conferem acesso em sigilo e siga as orientações de autenticação de cada endpoint.

Como gerar assinaturas

Como tudo isso funciona na prática?

O campo params típico ao criar uma Assembly sem Signature Authentication é o seguinte:

{
  "auth": {
    "key": "23c96d084c744219a2ce156772ec3211"
  },
  "steps": {
    // …
  }
}

A auth.key neste exemplo é a Auth Key das Credenciais da API na sua conta.

Para assinar essa solicitação, é necessário adicionar o campo auth.expires. Isso o adiciona ao nosso payload, que é protegido pela nossa assinatura. Se alguém o alterasse, a Transloadit rejeitaria a solicitação porque a assinatura não corresponderia mais. Você assinou um payload diferente daquele que recebemos. Se a assinatura corresponder, compararemos a data e rejeitaremos a solicitação conforme instruído. Dessa forma, fica muito difícil para um terceiro que tenha obtido esse payload repetir as solicitações indefinidamente. Embora nosso HTTPS com classificação A+ já ajude bastante a impedir isso, o cache do navegador pode ser mais fácil de inspecionar indevidamente.

A propriedade expires deve conter um timestamp em um futuro (próximo). Use o formato ISO 8601 (YYYY-MM-DDTHH:mm:ss.sssZ) para a data, garantindo que o fuso horário seja UTC. Por exemplo:

{
  "auth": {
    "key": "23c96d084c744219a2ce156772ec3211",
    "expires": "YOUR_FUTURE_ISO_8601_TIMESTAMP"
  },
  "steps": {
    // …
  }
}

Para calcular a assinatura dessa solicitação:

1. No front-end, serialize o objeto JavaScript acima em JSON e envie-o para seu back-end.
2. No back-end, calcule uma assinatura HMAC hexadecimal em conformidade com a RFC 6234⁠ sobre a string, usando seu Auth Secret como chave e o algoritmo configurado em signature_algo da sua Auth Key. Novas Auth Keys usam sha384 por padrão. Auth Keys legadas sem um algoritmo configurado aceitam sha384, sha256 ou sha1. Adicione ao início da string signature o nome do algoritmo em letras minúsculas. Por exemplo, o algoritmo padrão usa sha384:<HMAC-signature>. Você pode enviar essa string para o front-end (desde que tenha feito as verificações apropriadas para garantir que era uma solicitação legítima do seu front-end).
3. No front-end, adicione à solicitação um campo multipart POST signature contendo esse valor (por exemplo, com um campo oculto em um formulário HTML).

A solicitação completa deve ser semelhante à seguinte:

{
  "params": {
    "auth": {
      "key": "23c96d084c744219a2ce156772ec3211",
      "expires": "YOUR_FUTURE_ISO_8601_TIMESTAMP",
    },
    "nonce": "04ac6cb6-df43-41fb-a7fd-e5dd711a64e1",
    "steps": {
      // …
    },
  },
  "signature": "sha384:YOUR_SIGNATURE",
}

Quando a Transloadit recebe a solicitação, também geramos uma assinatura seguindo o mesmo processo e comparamos as duas assinaturas. Se forem diferentes, nossos servidores responderão com INVALID_SIGNATURE.

Em resumo, o processo é o seguinte:

1. Gere um payload JSON para enviar à Transloadit como o campo params.
2. Calcule uma assinatura com base no conteúdo do payload, usando seu Auth Secret como chave.
3. Envie a solicitação à Transloadit, com a assinatura no campo signature
4. A Transloadit calculará a mesma assinatura usando o Auth Secret da sua conta e o conteúdo do payload.
5. Se as assinaturas corresponderem, a solicitação será permitida e uma resposta apropriada será enviada. Caso contrário, a solicitação será negada e um erro será retornado com o código INVALID_SIGNATURE.

Isso permite que a Transloadit autentique quem faz a chamada e verifique a integridade de params, pois um terceiro não conseguiria calcular uma assinatura correspondente sem acesso ao seu Auth Secret. O TLS autentica a Transloadit perante seu cliente e protege a conexão. A assinatura de webhooks é um fluxo separado para solicitações que a Transloadit envia aos seus servidores.

Abaixo estão alguns exemplos de como fazer uma solicitação POST para criar uma Assembly. Recomendamos fortemente usar um dos nossos SDKs, que geram assinaturas automaticamente e são bem testados.

Exemplos de código para diferentes linguagens

Os exemplos abaixo demonstram a criação de Assemblies usando nossos SDKs oficiais. Os SDKs cuidam de toda a geração de assinaturas internamente, tornando a integração mais simples e segura.

// yarn add @transloadit/node
// or
// npm install --save @transloadit/node

import { Transloadit } from '@transloadit/node'

const transloadit = new Transloadit({
  authKey: 'YOUR_TRANSLOADIT_KEY',
  authSecret: 'YOUR_TRANSLOADIT_SECRET',
})

const response = await transloadit.createAssembly({
  params: {
    template_id: 'YOUR_TRANSLOADIT_TEMPLATE_ID',
    // your other params like notify_url, fields, etc.
  },
  waitForCompletion: true,
})

console.log(response)

const { signature, params } = transloadit.calcSignature({
  template_id: 'YOUR_TRANSLOADIT_TEMPLATE_ID',
})

console.log(signature, params)

curl --fail-with-body -sS --location 'https://api2.transloadit.com/assemblies' \
  --form 'params={"auth":{"key":"23c96d084c744219a2ce156772ec3211","expires":"YOUR_FUTURE_ISO_8601_TIMESTAMP"},"template_id":"9cf67cbba601e37ee10c442b037e0"}' \
  --form 'signature=sha384:YOUR_SIGNATURE' \
  --form 'files=@/path/to/your/file.jpg'

URLs assinadas do Smart CDN

Para assinar uma URL do Smart CDN, usa-se um processo semelhante ao das assinaturas comuns da API. Um resumo HMAC é calculado sobre uma string derivada da URL do Smart CDN, usando o Auth Secret como chave. Para que a assinatura seja válida, a Auth Key usada deve estar habilitada para uso com o Smart CDN.

A geração de uma assinatura do Smart CDN deve ser feita no back-end. O processo usa o Auth Secret, que é confidencial e não deve ser exposto aos seus usuários no front-end.

Uma URL típica do Smart CDN tem a seguinte estrutura:

https://[your-workspace].tlcdn.com/[template-name]/[file-path]?[parameters]

• [your-workspace] é o nome do seu Workspace da Transloadit
• [template-name] é o nome do seu Template
• [file-path] é o caminho do arquivo que você quer transformar
• [parameters] são os parâmetros de transformação desejados (por exemplo, h=100)

Uma URL assinada do Smart CDN é gerada seguindo estas etapas:

1. Adicione o parâmetro de consulta exp para definir um momento no futuro após o qual a assinatura não será mais aceita pelo Smart CDN. Isso é útil para limitar o acesso a um arquivo no tempo. O momento de expiração é representado pelo número de milissegundos desde a época UNIX (a meia-noite do início de 1º de janeiro de 1970, UTC). Embora esse parâmetro seja opcional, recomendamos fortemente sempre definir um momento de expiração. Por exemplo, uma assinatura com exp=1722517200000 é válida até quinta-feira, 01 de agosto de 2024 às 13:00:00 GMT.
2. Adicione o parâmetro de consulta auth_key para definir a Auth Key correspondente ao Auth Secret usado para criar a assinatura. Se esse parâmetro não estiver definido, a API da Transloadit presume que o par da Auth Key mais antiga habilitada para Smart CDN foi usado na assinatura. Definir o parâmetro auth_key permite alternar sua Auth Key sem interromper seus usuários, por isso recomendamos fortemente defini-lo. Por exemplo: auth_key=23c96d084c744219a2ce156772ec3211
3. Ordene os parâmetros de consulta por chave em ordem crescente usando unidades de código UTF-16, conforme URLSearchParams.sort(). A ordenação deve ser estável, ou seja, se uma chave aparecer várias vezes na string de consulta, os valores correspondentes devem manter sua ordem relativa. Por exemplo, h=100&f=png&f=jpg&auth_key=hello&exp=123 é ordenado como auth_key=hello&exp=123&f=png&f=jpg&h=100.
4. Construa a string a ser assinada concatenando os valores:

   [your-workspace]/[template-name]/[file-path]?[sorted-parameters]
   

   Os valores de [your-workspace], [template-name] e [file-path] devem ser codificados para URL para garantir que contenham apenas caracteres seguros para URLs. Observe que a string não começa com uma barra. O caractere ? deve ser omitido se [sorted-parameters] estiver vazio.
5. Calcule uma assinatura HMAC hexadecimal em conformidade com a RFC 6234⁠ sobre a string a ser assinada, usando seu Auth Secret como chave e SHA256 como algoritmo de hash. Adicione ao início da assinatura hexadecimal o nome do algoritmo em letras minúsculas e dois-pontos, ou seja, sha256:. Por exemplo, para SHA256, use sha256:[hmac-signature].
6. Acrescente à URL a assinatura hexadecimal com prefixo no parâmetro de consulta sig, obtendo a URL assinada do Smart CDN:

   https://[your-workspace].tlcdn.com/[template-name]/[file-path]?[parameters]&sig=sha256:[hmac-signature]
   

   Os valores de [your-workspace], [template-name] e [file-path] devem ser codificados para URL para garantir que contenham apenas caracteres seguros para URLs. Essa URL assinada pode então ser enviada ao seu front-end ou usada nele até que a data de expiração seja atingida.

Segurança e tempo de vida do cache

As URLs assinadas do Smart CDN não são apenas um mecanismo de controle de acesso. Sua expiração também determina por quanto tempo um resultado recém-gerado pode continuar elegível para armazenamento em cache.

• Valores de exp mais próximos reduzem a janela de reutilização da solicitação e tornam o controle de acesso mais restrito.
• Valores de exp mais distantes aumentam a reutilização do cache, reduzem o trabalho na origem e geralmente diminuem a latência e o volume de codificação.
• Na prática, o tempo de vida efetivo do cache de uma resposta assinada do Smart CDN é limitado pelo tempo de vida restante da assinatura.

Isso significa que a relação entre os fatores é direta:

• Maior sensibilidade à segurança: use um exp mais próximo, o que também significa um TTL efetivo de cache mais curto.
• Maior reutilização do cache e menor custo: use um exp mais distante, o que também significa que a URL continuará utilizável por mais tempo.

Escolha a janela de expiração de acordo com a sensibilidade do conteúdo e o quanto você deseja reutilizar o cache. Para muitos casos de uso de imagens e prévias, uma janela de expiração moderada oferece um bom equilíbrio. Para conteúdo altamente sensível, use uma janela muito mais curta.

Exemplos de código

Abaixo você encontra exemplos em diferentes linguagens para gerar URLs assinadas do Smart CDN usando nossos SDKs.

// yarn add @transloadit/node
// or
// npm install --save @transloadit/node

import { Transloadit } from '@transloadit/node'

const transloadit = new Transloadit({
  authKey: 'YOUR_TRANSLOADIT_KEY',
  authSecret: 'YOUR_TRANSLOADIT_SECRET',
})

const url = transloadit.getSignedSmartCDNUrl({
  workspace: 'YOUR_WORKSPACE',
  template: 'YOUR_TEMPLATE',
  input: 'image.png',
  urlParams: { height: 100, width: 100 },
})

console.log(url)

Acesso de leitura após o cancelamento

Workspaces cancelados não podem criar novos tokens bearer. Os endpoints que permitem explicitamente o acesso após o cancelamento apontam para esta receita. Use uma Auth Key ativa já existente e seu Auth Secret; a chave ainda deve conceder os escopos listados para o endpoint. Isso não restaura o acesso de escrita nem disponibiliza outros endpoints após o cancelamento.

Em um projeto Node.js confiável executado no servidor, instale o SDK com yarn add @transloadit/node. Defina TRANSLOADIT_KEY e TRANSLOADIT_SECRET e, em seguida, defina TRANSLOADIT_URL com a URL HTTPS completa mostrada na página do endpoint, substituindo os parâmetros de caminho pelos valores do seu recurso. Mantenha ambas as credenciais, a URL assinada e a resposta em sigilo. Nunca execute essa configuração no código do navegador.

O SDK assina params com sha384, o padrão para novas Auth Keys, e fornece a expiração. O exemplo adiciona um novo nonce para evitar a reutilização de assinaturas. Se sua chave usar outro algoritmo de assinatura, passe-o como segundo argumento de calcSignature. Coloque os filtros do endpoint dentro do objeto passado como primeiro argumento, junto com o nonce. O SDK não chama /token nesta receita.

Salve o conteúdo a seguir como read-api.mjs e execute node read-api.mjs:

import { randomUUID } from 'node:crypto'

import { Transloadit } from '@transloadit/node'

const { TRANSLOADIT_KEY, TRANSLOADIT_SECRET, TRANSLOADIT_URL } = process.env
if (!TRANSLOADIT_KEY || !TRANSLOADIT_SECRET || !TRANSLOADIT_URL) {
  throw new Error('Set TRANSLOADIT_KEY, TRANSLOADIT_SECRET, and TRANSLOADIT_URL')
}
const transloadit = new Transloadit({
  authKey: TRANSLOADIT_KEY,
  authSecret: TRANSLOADIT_SECRET,
})
const { params, signature } = transloadit.calcSignature({ nonce: randomUUID() })
const url = new URL(TRANSLOADIT_URL)
url.searchParams.set('params', params)
url.searchParams.set('signature', signature)
const response = await fetch(url, { redirect: 'error' })
if (!response.ok) throw new Error(`HTTP ${response.status}: ${await response.text()}`)
const result = await response.json()
if (result.error) throw new Error(result.error)
console.log(JSON.stringify(result, null, 2))

Conectar um cliente MCP por URL

Clientes de agentes como ChatGPT, Codex, Claude.ai, Claude Desktop, Claude Code e Cursor se conectam ao servidor MCP hospedado em https://api2.transloadit.com/mcp usando apenas essa URL. A API da Transloadit é um servidor de autorização OAuth 2.1 para ele: o cliente descobre os endpoints, identifica-se, encaminha você ao Console para fazer login e consentir e obtém um token Bearer de curta duração para o público-alvo mcp, além de um token de atualização. Nenhum Auth Secret sai da sua conta.

1. Descoberta. O servidor MCP responde a solicitações não autenticadas com 401 e um cabeçalho WWW-Authenticate: Bearer resource_metadata="https://api2.transloadit.com/.well-known/oauth-protected-resource/mcp". Esse documento da RFC 9728⁠ indica https://api2.transloadit.com como servidor de autorização, cujos metadados da RFC 8414⁠ em https://api2.transloadit.com/.well-known/oauth-authorization-server listam os endpoints abaixo.
2. Identificação do cliente. Apresente um Documento de Metadados de ID de Cliente⁠: uma URL HTTPS que é o client_id e serve JSON com o mesmo client_id, um client_name e os redirect_uris. Ou registre-se uma vez por meio do registro dinâmico de clientes da RFC 7591⁠ em https://api2.transloadit.com/oauth/register; os clientes enviam apenas seu client_id (token_endpoint_auth_method: "none", também quando omitido), autenticam-se com um segredo de cliente (client_secret_basic ou client_secret_post) ou autenticam-se com private_key_jwt e um jwks_uri. A resposta contém um client_id opaco, além de um client_secret para os métodos com segredo, que é exibido apenas nessa resposta. Os URIs de redirecionamento devem ser URLs HTTPS, com correspondência exata, ou URLs de loopback http://localhost / http://127.0.0.1, com correspondência em qualquer porta. Um cliente registrado com um segredo o envia em todas as solicitações de token e revogação, por HTTP Basic ou como client_id e client_secret no formulário. Outras solicitações de token autenticam o cliente com none ou private_key_jwt, conforme listado no documento dele (em token_endpoint_auth_methods_supported ou, na ausência deste, em token_endpoint_auth_method) ou declarado no registro. A primeira solicitação de token vincula a concessão ao método usado: depois que uma solicitação para uma concessão inclui um client_assertion da RFC 7523⁠, todas as solicitações posteriores de token e revogação para ela também devem incluir um. Essa asserção é um JWT assinado (RS256 ou ES256) com uma chave do jwks_uri do cliente, com o ID do cliente como iss e sub. Seu aud é uma URL de endpoint de token configurada ou a origem dela (sem barra final) para esta implantação. Ela tem um exp dentro de cinco minutos e um jti que é aceito uma vez por cliente por região enquanto a asserção permanece válida. Use um novo jti para cada solicitação.
3. Consentimento. O cliente abre https://transloadit.com/c/oauth/authorize com response_type=code, seu client_id, redirect_uri, um code_challenge PKCE (somente S256), opcionalmente scope e state, e resource=https://api2.transloadit.com/mcp. Você faz login, escolhe um Workspace e aprova; o Console redireciona o navegador de volta com code, seu state e iss=https://api2.transloadit.com. O código é vinculado ao cliente, ao URI de redirecionamento, ao desafio e ao Workspace, e expira após 120 segundos.
4. Tokens. O cliente envia por POST grant_type=authorization_code com code, code_verifier, client_id e redirect_uri para https://api2.transloadit.com/token e recebe um access_token (válido por 604.800 segundos, 7 dias, por padrão), seu scope e um refresh_token. Enviar por POST grant_type=refresh_token com refresh_token e client_id retorna um novo par e retira de uso o token de atualização apresentado; tokens de atualização têm validade de 30 dias, e reutilizar um token retirado de uso revoga toda a linhagem. Clientes que se autenticam com um segredo de cliente recebem de volta o mesmo token de atualização, válido por mais 30 dias a partir dessa atualização.
5. Revogação. Envie token (um token de acesso ou de atualização) por POST para https://api2.transloadit.com/oauth/revoke conforme a RFC 7009⁠, ou revogue a conexão no Console.

O indicador resource (RFC 8707⁠) determina a finalidade do token. resource=https://api2.transloadit.com/mcp (o padrão quando omitido) emite um token mcp que contém, no máximo, os escopos seguros de MCP (assemblies:write, assemblies:read, templates:read), limitados ao que a Auth Key do Workspace concede, e que somente o servidor MCP aceita. resource=https://api2.transloadit.com (com ou sem barra final) emite um token api2 para aplicações que chamam a REST API diretamente, como integrações do Vercel Connect⁠: ele contém os escopos solicitados limitados aos escopos da Auth Key, ou tudo o que a chave concede quando scope é omitido, com a exceção de que uma concessão nunca inclui o gerenciamento de Auth Keys ou credenciais de Template (auth_keys:*, template_credentials:* ou os escopos globais read/write que os implicam), portanto ela não pode criar nem revelar credenciais duradouras. Qualquer outro resource recebe invalid_target como resposta.

Erros do protocolo OAuth no registro de clientes, na autorização e na revogação usam o corpo padrão com error e error_description; limites de taxa podem retornar RATE_LIMIT_REACHED.

Em /token, erros de concessão OAuth para authorization_code e refresh_token usam o corpo padrão com error e error_description. Limites de taxa retornam RATE_LIMIT_REACHED (429), e falhas internas inesperadas retornam SERVER_500 (500). Solicitações malformadas rejeitadas antes que a concessão seja identificada podem receber um desafio HTTP Basic (401), ou TOKEN_INVALID_REQUEST se credenciais Basic tiverem sido fornecidas.

Tokens bearer (credenciais de cliente)

Tarefas de CI, servidores e outros clientes sem interface que possuem uma Auth Key e um Auth Secret trocam essas credenciais por um token Bearer de curta duração com a concessão OAuth 2.0 client_credentials, processada diretamente pela API da Transloadit. Use isso quando não houver um navegador para dar consentimento; clientes MCP interativos devem se conectar por URL conforme descrito acima. Para a referência completa do endpoint, consulte a documentação da API /token.

Como usar o token

Passe o token como Authorization: Bearer <access_token> nas solicitações à API. Quando uma solicitação é autenticada com um token Bearer válido, a API2 considera a Signature Authentication atendida e pula a validação da assinatura. A Signature Authentication é exigida apenas em solicitações com chave/segredo. As verificações de escopo e público-alvo continuam se aplicando. O público-alvo mcp é aceito pelo servidor MCP, que o encaminha à API2 com uma credencial de serviço; ele é rejeitado quando apresentado diretamente aos endpoints comuns da API2. Você pode omitir auth.key em params, mas o envelope params ainda é obrigatório para endpoints que o esperam.

curl --fail-with-body -sS --request POST \
  --url 'https://api2.transloadit.com/assemblies' \
  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN' \
  --form 'params={"template_id":"YOUR_TEMPLATE_ID"}'

Autenticação automática de MCP para /ai/chat

Se seus Steps /ai/chat chamarem um servidor MCP hospedado pela Transloadit, a API2 poderá emitir e inserir um token Bearer de curta duração automaticamente (autenticação automática). Isso exige ativação explícita em cada entrada de servidor MCP:

{
  "mcp_servers": [
    {
      "type": "http",
      "url": "https://api2.transloadit.com/mcp",
      "auth": "transloadit"
    }
  ]
}

Comportamento:

• Se auth: "transloadit" estiver definido e não houver um cabeçalho Authorization, a API2 emitirá um token e inserirá Authorization: Bearer <token>.
• Se Authorization já tiver sido fornecido em mcp_servers[].headers, ele será mantido sem alterações.
• A autenticação automática só funciona por HTTPS para hosts de domínio raiz e subdomínios gerenciados pela Transloadit: transloadit.com, *.transloadit.com, transloadit.dev, *.transloadit.dev, transloadit.website, *.transloadit.website, transloadit.work, *.transloadit.work.
• A URL deve usar a porta 443 e o caminho exato /mcp ou um subcaminho abaixo de /mcp/.
• A URL não deve conter credenciais, string de consulta ou fragmento.
• A Auth Key deve conceder pelo menos um destes escopos seguros de MCP: assemblies:write, assemblies:read, templates:read.
• O token emitido é limitado à interseção desses escopos seguros de MCP com os escopos da Auth Key; ele nunca recebe um escopo que a Auth Key não conceda.

Perguntas frequentes

A Transloadit inclui assinaturas nas solicitações que envia?

A Transloadit assina solicitações de webhook para que seu servidor possa verificar sua autenticidade. A assinatura de webhooks é separada do HMAC que autentica solicitações à API enviadas à Transloadit.

Por que não posso usar meu Auth Secret como token Bearer?

Exceto na troca de tokens entre servidores descrita acima, seu Auth Secret nunca deve ser transmitido a um cliente nem incluído nos parâmetros de solicitações à API. POST /token o envia como a senha HTTP Basic por HTTPS e deve ser chamado apenas pelo seu back-end. Para solicitações assinadas, o segredo permanece no back-end e é usado como chave HMAC. Isso impede que um agente mal-intencionado intercepte uma solicitação assinada e falsifique solicitações à sua conta. Mantenha seu Auth Secret seguro usando o sistema de gerenciamento de segredos que preferir. Alguns exemplos são: Vault⁠, AWS Secrets Manager⁠, GCP Secret Manager⁠ e Kubernetes Secrets⁠, mas há muitos outros que podem ser adequados, dependendo da plataforma de back-end escolhida.

Em que ordem as chaves do corpo precisam estar?

A ordem que você escolher para as chaves do corpo pode ser arbitrária, mas é importante observar que qualquer ordem escolhida precisa ser consistente com a geração da assinatura. O hash gerado depende do conteúdo do JSON, e uma ordenação diferente gerará um hash diferente, o que significa que sua solicitação será negada.