# Pontos de extremidade da API REST para envio de dependências

Use a API REST para enviar dependências.

## Sobre as submissões de dependências

Você pode usar a API REST para enviar dependências para um projeto. Isso permite que você adicione dependências, como aquelas resolvidas quando o software é compilado ou gerado, ao recurso de grafo de dependências do GitHub, fornecendo uma visão mais completa de todas as dependências do seu projeto.

O gráfico mostra todas as dependências que você envia usando a API, além de quaisquer dependências identificadas por meio de arquivos de manifesto ou de bloqueio no repositório (por exemplo, um arquivo `package-lock.json` em um projeto JavaScript). Para obter mais informações sobre exibição do grafo de dependência, confira [Explorar as dependências de um repositório](/pt/enterprise-server@3.22/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/explore-dependencies#viewing-the-dependency-graph).

As dependências submetidas receberão Dependabot alerts e Dependabot security updates para qualquer vulnerabilidade conhecida. Você só obterá Dependabot alerts para dependências provenientes de um dos ecossistemas compatíveis com o GitHub Advisory Database. Para saber mais sobre esses ecossistemas, confira [Banco de dados do GitHub Advisory](/pt/enterprise-server@3.22/code-security/concepts/vulnerability-reporting-and-management/github-advisory-database#github-reviewed-vulnerability-advisories). Para dependências transitivas enviadas via API de envio de dependência, Dependabot abrirá automaticamente solicitações de pull para atualizar a dependência pai, se houver uma atualização disponível.

As dependências enviadas estão disponíveis nos insights de dependência da sua organização.

É possível enviar dependências na forma de um instantâneo. Um instantâneo é um conjunto de dependências associadas a um SHA de commit e a outros metadados, que reflete o estado atual do repositório de um commit. É possível optar por usar ações predefinidas ou criar suas próprias ações para enviar suas dependências no formato necessário sempre que seu projeto for criado. Para saber mais, confira [Usar a API de envio de dependências](/pt/enterprise-server@3.22/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/use-dependency-submission-api).

É possível enviar diversos conjuntos de dependências para serem incluídos em seu grafo de dependência. A API REST usa a propriedade `job.correlator` e a categoria `detector.name` do instantâneo para garantir que os envios mais recentes para cada fluxo de trabalho sejam exibidos. A propriedade `correlator` em si é o campo primário que você usará para diferenciar os envios independentes. Um `correlator` de exemplo pode ser uma combinação simples de duas variáveis disponíveis em execuções de ações: `<GITHUB_WORKFLOW> <GITHUB_JOB>`.

Um repositório pode usar vários métodos para submissão de dependências, o que pode resultar no manifesto do mesmo pacote sendo analisado múltiplas vezes, potencialmente produzindo saídas diferentes a cada análise. O grafo de dependência usa a lógica de deduplicação para analisar as saídas, priorizando as informações mais precisas para cada arquivo de manifesto.

O grafo de dependência exibe apenas uma instância de cada arquivo de manifesto usando as regras de precedência a seguir.

1. **Os envios de usuário** têm a prioridade mais alta, pois geralmente são criados durante compilações de artefatos que têm as informações mais completas.
   * Se houver vários instantâneos manuais de detectores diferentes, eles serão classificados em ordem alfabética por correlator e pelo primeiro usado.
   * Se houver dois correlacionadores com o mesmo detector, as dependências resolvidas serão mescladas. Para obter mais informações sobre correlacionadores e detectores, consulte [Pontos de extremidade da API REST para envio de dependências](/pt/enterprise-server@3.22/rest/dependency-graph/dependency-submission).
2. **Os envios automáticos** têm a próxima prioridade, pois também são criados durante builds de artefato, mas não são enviados pelos usuários.
3. **Os resultados da análise estática** são usados quando nenhum outro dado está disponível.

> \[!NOTE]
> Most endpoints use `Authorization: Bearer <YOUR-TOKEN>` and `Accept: application/vnd.github+json` headers, plus `X-GitHub-Api-Version: 2026-03-10`. Curl examples below omit these standard headers for brevity.

## Create a snapshot of dependencies for a repository

```
POST /repos/{owner}/{repo}/dependency-graph/snapshots
```

Create a new snapshot of a repository's dependencies.
The authenticated user must have access to the repository.
OAuth app tokens and personal access tokens (classic) need the repo scope to use this endpoint.

### Parameters

#### Headers

* **`accept`** (string)
  Setting to `application/vnd.github+json` is recommended.

#### Path and query parameters

* **`owner`** (string) (required)
  The account owner of the repository. The name is not case sensitive.

* **`repo`** (string) (required)
  The name of the repository without the .git extension. The name is not case sensitive.

#### Body parameters

* **`version`** (integer) (required)
  The version of the repository snapshot submission.

* **`job`** (object) (required)
  * **`id`** (string) (required)
    The external ID of the job.
  * **`correlator`** (string) (required)
    Correlator provides a key that is used to group snapshots submitted over time. Only the "latest" submitted snapshot for a given combination of job.correlator and detector.name will be considered when calculating a repository's current dependencies. Correlator should be as unique as it takes to distinguish all detection runs for a given "wave" of CI workflow you run. If you're using GitHub Actions, a good default value for this could be the environment variables GITHUB\_WORKFLOW and GITHUB\_JOB concatenated together. If you're using a build matrix, then you'll also need to add additional key(s) to distinguish between each submission inside a matrix variation.
  * **`html_url`** (string)
    The url for the job.

* **`sha`** (string) (required)
  The commit SHA associated with this dependency snapshot. Maximum length: 40 characters.

* **`ref`** (string) (required)
  The repository branch that triggered this snapshot.

* **`detector`** (object) (required)
  A description of the detector used.
  * **`name`** (string) (required)
    The name of the detector used.
  * **`version`** (string) (required)
    The version of the detector used.
  * **`url`** (string) (required)
    The url of the detector used.

* **`metadata`** (object)
  User-defined metadata to store domain-specific information limited to 8 keys with scalar values.

* **`manifests`** (object)
  A collection of package manifests, which are a collection of related dependencies declared in a file or representing a logical group of dependencies.
  * **`key`** (object)
    A user-defined key to represent an item in manifests.
    * **`name`** (string) (required)
      The name of the manifest.
    * **`file`** (object)
      * **`source_location`** (string)
        The path of the manifest file relative to the root of the Git repository.
    * **`metadata`** (object)
      User-defined metadata to store domain-specific information limited to 8 keys with scalar values.
    * **`resolved`** (object)
      A collection of resolved package dependencies.
      * **`key`** (object)
        A user-defined key to represent an item in resolved.
        * **`package_url`** (string)
          Package-url (PURL) of dependency. See <https://github.com/package-url/purl-spec> for more details.
        * **`metadata`** (object)
          User-defined metadata to store domain-specific information limited to 8 keys with scalar values.
        * **`relationship`** (string)
          A notation of whether a dependency is requested directly by this manifest or is a dependency of another dependency.
          Can be one of: `direct`, `indirect`
        * **`scope`** (string)
          A notation of whether the dependency is required for the primary build artifact (runtime) or is only used for development. Future versions of this specification may allow for more granular scopes.
          Can be one of: `runtime`, `development`
        * **`dependencies`** (array of strings)
          Array of package-url (PURLs) of direct child dependencies.

* **`scanned`** (string) (required)
  The time at which the snapshot was scanned.

### HTTP response status codes

* **201** - Created

### Code examples

#### Example

**Request:**

```curl
curl -L \
  -X POST \
  http(s)://HOSTNAME/api/v3/repos/OWNER/REPO/dependency-graph/snapshots \
  -d '{
  "version": 0,
  "sha": "ce587453ced02b1526dfb4cb910479d431683101",
  "ref": "refs/heads/main",
  "job": {
    "correlator": "yourworkflowname_youractionname",
    "id": "yourrunid"
  },
  "detector": {
    "name": "octo-detector",
    "version": "0.0.1",
    "url": "https://github.com/octo-org/octo-repo"
  },
  "scanned": "2022-06-14T20:25:00Z",
  "manifests": {
    "package-lock.json": {
      "name": "package-lock.json",
      "file": {
        "source_location": "src/package-lock.json"
      },
      "resolved": {
        "@actions/core": {
          "package_url": "pkg:/npm/%40actions/core@1.1.9",
          "dependencies": [
            "@actions/http-client"
          ]
        },
        "@actions/http-client": {
          "package_url": "pkg:/npm/%40actions/http-client@1.0.7",
          "dependencies": [
            "tunnel"
          ]
        },
        "tunnel": {
          "package_url": "pkg:/npm/tunnel@0.0.6"
        }
      }
    }
  }
}'
```

**Response schema (Status: 201):**

* `id`: required, integer
* `created_at`: required, string
* `result`: required, string
* `message`: required, string