# Puntos de conexión de la API de REST para el envío de dependencias

Usa la API de REST para enviar dependencias.

## Acerca de las presentaciones de dependencias

Puedes usar la API REST para enviar dependencias para un proyecto. Esto te permite añadir dependencias, como las que se resuelven cuando el software se compila o se genera, a la función de grafo de dependencias de GitHub, lo que proporciona una visión más completa de todas las dependencias de tu proyecto.

El gráfico de dependencias muestra las dependencias que envías mediante la API, además de las dependencias identificadas mediante archivos de bloqueo o de manifiesto en el repositorio (por ejemplo, un archivo `package-lock.json` en un proyecto de JavaScript). Para más información sobre cómo ver el gráfico de dependencias, consulta [Explorar las dependencias de un repositorio](/es/enterprise-server@3.22/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/explore-dependencies#viewing-the-dependency-graph).

Las dependencias enviadas recibirán Dependabot alerts y Dependabot security updates para cualquier vulnerabilidad conocida. Solo obtendrás Dependabot alerts para las dependencias que procedan de uno de los ecosistemas compatibles con GitHub Advisory Database. Para más información sobre estos ecosistemas, consulta [Base de datos de asesoramiento de GitHub](/es/enterprise-server@3.22/code-security/concepts/vulnerability-reporting-and-management/github-advisory-database#github-reviewed-vulnerability-advisories). Para las dependencias transitivas enviadas mediante API de envío de dependencias, Dependabot abrirá automáticamente pull requests para actualizar la dependencia principal, si hay una actualización disponible.

Las dependencias enviadas *no* están disponibles en la información de dependencias de la organización.

Puede enviar dependencias en forma de captura instantánea. Una instantánea es un conjunto de dependencias asociadas a un SHA de confirmación y otros metadatos, que refleja el estado actual del repositorio para una confirmación. Puedes optar por usar acciones realizadas previamente o crear tus propias acciones para enviar las dependencias en el formato necesario cada vez que se compila el proyecto. Para más información, consulta [Uso de la Dependency submission API](/es/enterprise-server@3.22/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/use-dependency-submission-api).

Puedes enviar varios conjuntos de dependencias para su inclusión en el gráfico de dependencias. La API de REST usa la propiedad `job.correlator` y la categoría `detector.name` de la instantánea para garantizar que se muestren los envíos más recientes para cada flujo de trabajo. La propiedad `correlator` en sí misma es el campo principal que usarás para distinguir los envíos independientes. Una propiedad `correlator` de ejemplo podría ser una simple combinación de dos variables disponibles en las ejecuciones de acciones: `<GITHUB_WORKFLOW> <GITHUB_JOB>`.

Un repositorio puede utilizar múltiples métodos para la presentación de dependencias, lo que puede hacer que el mismo manifiesto de paquete se analice varias veces, potencialmente con resultados diferentes de cada análisis. El gráfico de dependencias usa lógica de desduplicación para analizar las salidas y priorizar la información más precisa para cada archivo de manifiesto.

El gráfico de dependencias muestra solo una instancia de cada archivo de manifiesto mediante las siguientes reglas de precedencia.

1. **Los envíos de usuario** tienen la prioridad más alta, ya que normalmente se crean durante las compilaciones de artefactos que tienen la información más completa.
   * Si hay varias instantáneas manuales de diferentes detectores, se ordenan alfabéticamente por correlación y la primera usada.
   * Si hay dos correladores con el mismo detector, se combinan las dependencias resueltas. Para obtener más información sobre los correladores y detectores, consulte [Puntos de conexión de la API de REST para el envío de dependencias](/es/enterprise-server@3.22/rest/dependency-graph/dependency-submission).
2. **Los envíos automáticos** tienen la siguiente prioridad, ya que también se crean durante las compilaciones de artefactos, pero los usuarios no los envían.
3. **Los resultados de análisis estáticos** se usan cuando no hay otros datos disponibles.

> \[!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