Autenticação

Auth Keys

Para requisiçõ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 desse tipo é mostrado abaixo.

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

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

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

Signature Authentication

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

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

Para criar Assemblies com a Transloadit, seu back-end pode calcular uma assinatura que cubra apenas determinados parâmetros, usuários autenticados e um intervalo de tempo que ele considere uso legítimo. Por exemplo, ele se recusaria a gerar uma assinatura para usuários que não estão logados. Aqui você pode usar qualquer lógica de negócio no lado do servidor para decidir se entrega uma assinatura ou não. A Transloadit pode exigir uma assinatura correta para o payload quando uma requisição de API se autentica com a sua Auth Key.

Para exigir a Signature Authentication em requisições de API autenticadas com a sua Auth Key:

1. Acesse as Configurações do Workspace na sua conta.
2. Na seção Configurações de 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 continuam valendo. Essas configurações não adicionam autenticação ao acesso baseado em capacidade, como URLs de status da Assembly, de cancelamento ou de uploads retomáveis. Mantenha os Assembly IDs e as URLs de capacidade em sigilo e siga as orientações de autenticação de cada endpoint.

Como gerar assinaturas

Então, como fica tudo isso na prática?

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

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

O campo auth.key neste exemplo é a Auth Key das Credenciais de API na sua conta.

Para assinar esta requisição, é preciso adicionar o campo extra auth.expires. Isso o inclui no nosso payload, que é protegido pela nossa assinatura. Se alguém o alterasse, a Transloadit rejeitaria a requisição, pois a assinatura não corresponderia mais. Você teria assinado um payload diferente daquele que recebemos. Se a assinatura corresponder, naturalmente compararemos a data e rejeitaremos conforme instruído. Dessa forma, fica muito difícil para um terceiro que tenha obtido esse payload repetir as requisições indefinidamente. Afinal, embora o nosso HTTPS com nota A+ já ajude bastante a evitar isso, o cache do navegador pode ser mais fácil de bisbilhotar.

A propriedade expires deve conter um timestamp no 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 desta requisição:

1. No seu front-end, converta o objeto JavaScript acima em uma string JSON e envie-a ao seu back-end.
2. No seu back-end, calcule uma assinatura HMAC hexadecimal compatível com a RFC 6234⁠ sobre a string, usando o seu Auth Secret como chave e o algoritmo configurado no 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. Prefixe a string signature com o nome do algoritmo em minúsculas. Por exemplo, o algoritmo padrão usa sha384:<HMAC-signature>. Você pode enviar essa string ao seu front-end (desde que tenha feito as verificações adequadas para garantir que a requisição veio realmente do seu front-end).
3. No seu front-end, adicione à sua requisição um campo POST multipart signature contendo esse valor (por exemplo, com um campo oculto em um formulário HTML).

A requisição completa deve ser semelhante a esta:

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

Assim que a requisição é recebida pela Transloadit, também geramos uma assinatura seguindo o mesmo processo e comparamos as duas assinaturas. Se as assinaturas 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 o seu Auth Secret como chave.
3. Envie a requisição à Transloadit, com a assinatura passada 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 coincidirem, a requisição é permitida e uma resposta adequada é enviada. Caso contrário, a requisição é negada e um erro com o código INVALID_SIGNATURE é retornado.

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

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

Exemplos de código para diferentes linguagens

Os exemplos abaixo mostram como criar Assemblies usando nossos SDKs oficiais. Os SDKs cuidam internamente de toda a geração de assinaturas, tornando a integração mais simples e mais 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, é usado um processo semelhante ao das assinaturas normais da API. Um digest HMAC é calculado sobre uma string derivada da URL do Smart CDN, com 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 para o arquivo que você deseja 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 query exp para definir um momento no futuro após o qual a assinatura não é mais aceita pelo Smart CDN. Isso é útil para limitar temporalmente o acesso a um arquivo. 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 enfaticamente definir sempre um prazo de expiração. Por exemplo, uma assinatura com exp=1722517200000 é válida até quinta-feira, 1º de agosto de 2024, às 13:00:00 GMT.
2. Adicione o parâmetro de query auth_key para definir a Auth Key correspondente ao Auth Secret usado para criar a assinatura. Se esse parâmetro não for definido, a API da Transloadit presume que o par de Auth Key mais antigo habilitado para o Smart CDN foi usado na assinatura. Definir o parâmetro auth_key permite rotacionar a sua Auth Key sem interromper seus usuários, por isso recomendamos enfaticamente defini-lo. Por exemplo: auth_key=23c96d084c744219a2ce156772ec3211
3. Ordene os parâmetros de query por chave em ordem crescente usando unidades de código UTF-16, da mesma forma que URLSearchParams.sort(). A ordenação deve ser estável, ou seja, se uma chave aparecer várias vezes na query string, 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 URL. 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 compatível com a RFC 6234⁠ sobre a string a ser assinada, com o seu Auth Secret como chave e SHA256 como algoritmo de hash. Prefixe a assinatura hexadecimal com o nome do algoritmo em minúsculas e dois-pontos, ou seja, sha256:. Por exemplo, para SHA256, use sha256:[hmac-signature].
6. Anexe à URL a assinatura hexadecimal prefixada no parâmetro de query 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 URL. 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

URLs assinadas do Smart CDN não são apenas um mecanismo de controle de acesso. A expiração delas também determina por quanto tempo um resultado recém-gerado pode permanecer armazenável em cache.

• Valores de exp mais curtos reduzem a janela de repetição e tornam o controle de acesso mais rigoroso.
• Valores de exp mais longos 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 escolha é simples:

• Mais sensibilidade de segurança: use um exp mais curto, o que também significa um TTL de cache efetivo mais curto.
• Mais reutilização de cache e menor custo: use um exp mais longo, o que também significa que a URL continua utilizável por mais tempo.

Escolha a janela de expiração de acordo com a sensibilidade do conteúdo e com o quanto de reutilização de cache você deseja. 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 bem 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 existente e o respectivo Auth Secret; a chave ainda precisa 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 no lado do 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 exibida na página do endpoint, substituindo quaisquer parâmetros de caminho pelos valores do seu recurso. Mantenha privadas as duas credenciais, a URL assinada e a resposta. Nunca execute esta configuração em código de navegador.

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

Salve isto 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 agente 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 atua como servidor de autorização OAuth 2.1 para ele: o cliente descobre os endpoints, se identifica, envia você ao Console para fazer login e dar consentimento e, por fim, obtém um token bearer de curta duração para o público mcp, além de um refresh token. Nenhum Auth Secret jamais sai da sua conta.

1. Descoberta. O servidor MCP responde a requisiçõ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 Client ID Metadata Document⁠: uma URL HTTPS que é o client_id e serve um JSON com o mesmo client_id, um client_name e os redirect_uris. Ou registre-se uma vez por meio do Dynamic Client Registration da RFC 7591⁠ em https://api2.transloadit.com/oauth/register; os clientes enviam apenas seu client_id (token_endpoint_auth_method: "none") ou se autenticam com private_key_jwt e um jwks_uri, e a resposta traz um client_id opaco. As 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. As requisições de token autenticam o cliente com none ou private_key_jwt, conforme o que o documento dele lista (em token_endpoint_auth_methods_supported ou, caso contrário, como token_endpoint_auth_method) ou o que o registro dele declara. A primeira requisição de token vincula a concessão ao método usado: assim que uma requisição para uma concessão traz um client_assertion da RFC 7523⁠, todas as requisições posteriores de token e de revogação para ela também precisam trazer 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. O aud dela é uma URL de endpoint de token configurada ou a origem dessa URL (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 permanecer válida. Use um jti novo em cada requisiçã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, o seu state e iss=https://api2.transloadit.com. O código fica vinculado ao cliente, à URI de redirecionamento, ao challenge e ao Workspace, e expira após 120 segundos.
4. Tokens. O cliente envia via 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), o respectivo scope e um refresh_token. Enviar via POST grant_type=refresh_token com refresh_token e client_id retorna um novo par e desativa o refresh token apresentado; refresh tokens duram 30 dias, e reutilizar um já desativado revoga toda a linhagem.
5. Revogação. Envie via POST token (um access token ou refresh token) para https://api2.transloadit.com/oauth/revoke, conforme a RFC 7009⁠, ou revogue a conexão no Console.

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

Os erros de protocolo OAuth de registro de cliente, autorização e revogação usam o corpo padrão com error e error_description; limites de taxa podem retornar RATE_LIMIT_REACHED.

Em /token, os 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). Requisições malformadas rejeitadas antes de a concessão ser 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 headless que possuem uma Auth Key e um Auth Secret os trocam por um token bearer de curta duração com a concessão client_credentials do OAuth 2.0, 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, como descrito acima. Para a referência completa do endpoint, consulte a documentação da API /token.

Como usar o token

Envie o token como Authorization: Bearer <access_token> nas requisições de API. Quando uma requisição é autenticada com um token bearer válido, a API2 considera a Signature Authentication atendida e ignora a validação da assinatura. A Signature Authentication é aplicada apenas a requisições com key/secret. As verificações de escopo e de público continuam valendo. O público mcp é aceito pelo servidor MCP, que repassa o token à API2 com uma credencial de serviço; ele é rejeitado quando apresentado diretamente aos endpoints normais da API2. Você pode omitir auth.key em params, mas o envelope params continua sendo obrigatório nos 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 os seus Steps de /ai/chat chamam um servidor MCP hospedado pela Transloadit, a API2 pode gerar e injetar automaticamente um token bearer de curta duração (auto-auth). Isso é opcional e ativado por 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 cabeçalho Authorization, a API2 gera um token e injeta Authorization: Bearer <token>.
• Se Authorization já for fornecido em mcp_servers[].headers, ele não é alterado.
• A auto-auth só funciona via HTTPS para hosts apex 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 exatamente o caminho /mcp ou um subcaminho abaixo de /mcp/.
• A URL não deve conter credenciais, query string nem fragmento.
• A Auth Key deve conceder pelo menos um destes escopos MCP seguros: assemblies:write, assemblies:read, templates:read.
• O token gerado é restrito à interseção desses escopos MCP seguros com os escopos da Auth Key; ele nunca recebe um escopo que a Auth Key não concede.

Perguntas frequentes

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

A Transloadit assina as requisições de Webhook para que o seu servidor possa verificar a autenticidade delas. A assinatura de webhooks é separada do HMAC que autentica as requisições de API enviadas à Transloadit.

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

Exceto na troca de tokens entre servidores descrita acima, o seu Auth Secret nunca deve ser transmitido a um cliente nem incluído nos parâmetros de requisições de API. POST /token o envia como senha HTTP Basic via HTTPS e deve ser chamado somente a partir do seu back-end. Em requisições assinadas, o secret permanece no seu back-end e é usado como chave do HMAC. Isso impede que um agente mal-intencionado intercepte uma requisição assinada e forje requisições para a sua conta. Mantenha o seu Auth Secret seguro usando o sistema de gerenciamento de segredos de sua preferência. 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 no corpo pode ser arbitrária; no entanto, é importante observar que a ordem escolhida precisa ser consistente com a geração da sua assinatura. O hash gerado depende do conteúdo do JSON, e uma ordem diferente gerará um hash diferente, o que significa que a sua requisição será negada.