# Signed Fetch Quando clientes de protocolo querem fazer requisições HTTPs autenticadas, eles podem aproveitar o padrão *signed fetch* mecanismo. Um signed fetch é requisição que inclui um [auth\_chain](https://docs.decentraland.org/contributor/contributor-pt/authentication/authchain), representado através de headers. Servidores com APIs compatíveis com Decentraland podem validar identidades antes, por exemplo, de [permitir requisições de cenas](https://github.com/decentraland/docs/blob/main/runtime/modules/signed_fetch.md) ou criar [adapters](https://github.com/decentraland/docs/blob/main/comms/overview.md). ## Headers A informação que o servidor precisa para validar a cadeia de autenticação é retransmitida em 3+ headers: * `X-Identity-Timestamp`: o `timestamp` campo incluído no payload assinado (veja abaixo). * `X-Identity-Metadata`: o `metadata` campo incluído no payload assinado (veja abaixo). * `X-Identity-AuthChain-`: o [etapa de autenticação serializada em JSON](https://docs.decentraland.org/contributor/contributor-pt/authchain#constructing) ``, começando de `0`. A cadeia transmitida é validada pelo servidor [conforme especificado](https://docs.decentraland.org/contributor/contributor-pt/authentication/authchain). ## Body O corpo da requisição não é especificado. Serviços têm plena flexibilidade para usar quaisquer protocolos ou formatos que desejarem. ## Payload A cadeia de autenticação [payload](https://docs.decentraland.org/contributor/contributor-pt/authchain#constructing) para um signed fetch é um **lower-case, colon-separated** string que inclui alguns dos elementos da requisição: ``` ::: ``` O `method` e `path` campos devem corresponder aos da requisição, e `timestamp` é o mesmo que no `X-Identity-Timestamp` header. O último campo, `metadata`, pode ter conteúdo arbitrário. Por exemplo: ``` get:/some/path:1682790056:{"some":"custom json"} ```