---
title: "Cómo se habilita tu acceso"
description: "El camino de un partner hasta su primera llamada: cuenta, solicitud de conexión, alcances, contrato del Art. 15 bis, credencial y modo sandbox."
url: "https://docs.edugoverna.com/gestion/acceso"
---
# Cómo se habilita tu acceso

Tu acceso a los datos de un colegio no se autoconfigura: existe porque ese colegio lo autorizó, con un alcance que él eligió y un contrato que él firmó. Esta página recorre ese camino de punta a punta y deja claro, en cada paso, qué hace el colegio y qué haces tú. {{ className: 'lead' }}

<Note>
  Esta página describe la relación, no una superficie que puedas llamar. Las
  rutas de `/api/integrations/*` que aparecen aquí las ejecuta el colegio con
  su sesión de consola o su API key de organización; tu credencial de partner
  no sirve en ellas y responden `401 API_KEY_REQUIRED`.
</Note>

## Quién hace qué

<Properties>
  <Property name="Cuenta de partner" type="Edugoverna">
    Tu espacio de trabajo y tu cuenta de partner las abre Edugoverna. No hay
    alta self-service: la ruta que lo permitía se retiró por escalada de
    privilegios.
  </Property>
  <Property name="Solicitud de conexión" type="Cualquiera de los dos">
    El colegio te invita (`school_invites_partner`) o tú pides acceso
    (`partner_requests_school`). La contraparte decide.
  </Property>
  <Property name="Alcances" type="El colegio">
    Qué espacios de recursos abre y en qué modo. Los pides; él los otorga.
  </Property>
  <Property name="Contrato del Art. 15 bis" type="El colegio">
    Lo registra en la conexión con su rango de vigencia. Sin uno vigente, la
    API te responde `403`.
  </Property>
  <Property name="Credencial" type="El colegio">
    La emite y te la entrega. El texto plano se muestra una sola vez.
  </Property>
  <Property name="Integración" type="Tú">
    Con la credencial —en sandbox o en producción— llamas la Partner API.
  </Property>
</Properties>

---

## Paso 1: tu cuenta de partner

Antes de que ningún colegio pueda conectarte, tiene que existir tu **cuenta de partner** (`partner_account`) y, si vas a operar campañas propias, tu **espacio de trabajo** (una organización de tipo `external_partner`). Ambas las provisiona Edugoverna: [escríbenos](https://www.edugoverna.com/partners/contacto) y las abrimos.

La cuenta de partner es la identidad que los colegios ven al conectarte. Lleva tu razón social, tu sitio, tu correo de contacto y el correo de privacidad al que se dirigen los avisos que la plataforma genera.

## Paso 2: la solicitud de conexión

La conexión es la relación formal entre un colegio y tu cuenta de partner, y nace de una solicitud que puede ir en cualquiera de las dos direcciones. En ambos casos, quien recibe la solicitud es quien la acepta.

<CodeGroup title="Solicitud" tag="POST" label="/api/integrations/connection-requests">

```bash {{ title: 'El partner pide acceso a un colegio' }}
curl https://app.edugoverna.com/api/integrations/connection-requests \
  -H "x-api-key: {api_key_del_partner}" \
  -H "Content-Type: application/json" \
  -d '{
    "direction": "partner_requests_school",
    "targetOrganizationId": "16fd2706-8baf-433b-82eb-8c7fada847da",
    "requestedScopes": [
      { "resourceNamespace": "subjects", "scopeType": "read" },
      { "resourceNamespace": "consents", "scopeType": "write" }
    ],
    "message": "Integración de consentimientos 2026"
  }'
```

</CodeGroup>

Al aceptarse, la plataforma crea la conexión con los alcances solicitados. Si la solicitud no traía alcances, se aplica un conjunto por defecto: `subjects` en lectura, `consents` en lectura y escritura, y `rights_requests` en lectura. Pide sólo lo que vas a usar: un alcance de más es una conversación de más en la evaluación del colegio.

El detalle completo de la API está en [Conexiones](/gestion/conexiones).

## Paso 3: el contrato del Art. 15 bis

Tratar datos de un colegio a través de tu plataforma te convierte en su **encargado de tratamiento**, y esa relación se rige por un contrato escrito. El colegio lo registra en la conexión con su rango de vigencia, y la plataforma lo trata como una compuerta dura: **sin un contrato vigente, toda llamada tuya se rechaza con `403 PARTNER_DPA_NOT_ACTIVE`** — no hay que acordarse de cerrar el acceso cuando el contrato vence.

Dos cosas que conviene saber antes de negociarlo:

- El artículo enumera lo que el contrato **deberá establecer**: el objeto del encargo, su duración, la finalidad del tratamiento, el tipo de datos tratados, las categorías de titulares y los derechos y obligaciones de las partes.
- Salirse del encargo tiene una consecuencia nombrada: si tratas los datos con un objeto distinto del convenido, o los cedes sin autorización expresa, la ley te considera **responsable para todos los efectos legales**, con responsabilidad personal por las infracciones y solidaria por los daños.

Cuando la conexión es de tipo `external_registry` —un colegio sin cuenta cuyo padrón carga un registrador externo— el instrumento que cumple esta compuerta no es un contrato sino la **declaración jurada firmada del registrador**. El recorrido completo está en la [guía del registrador externo](/guias/registrador-externo).

## Paso 4: la credencial

Con la conexión activa, el colegio emite tu credencial desde su consola (**Integraciones → Partners**) o por API, eligiendo qué permisos `partner.*` lleva. La llave en texto plano tiene la forma `keyId.secret` y **se muestra una sola vez**: Edugoverna guarda sólo su hash. Si se pierde, se revoca y se emite otra.

Una credencial también lleva su propio límite de tasa (por defecto 600 solicitudes cada 60 segundos) y un vencimiento opcional. Ver [Credenciales](/gestion/credenciales).

## Paso 5: prueba antes de tener datos reales

Una credencial puede emitirse en **modo sandbox** (`isSandbox: true`). En ese modo recorres el flujo completo —incluido el código de verificación del portal de consentimiento, que se devuelve en la respuesta— sin envíos reales a familias. Es la forma de integrar antes de tener el primer colegio en producción.

## Las cuatro puertas, y cómo saber cuál te frenó

Cada llamada tuya atraviesa cuatro compuertas en orden. Cada una tiene su código, así que un rechazo siempre dice cuál fue:

<Properties>
  <Property name="1 · Credencial" type="401">
    `PARTNER_BEARER_REQUIRED`, `PARTNER_CREDENTIAL_INVALID` o
    `PARTNER_CREDENTIAL_EXPIRED`.
  </Property>
  <Property name="2 · Conexión y espacio de trabajo" type="403">
    `PARTNER_CONNECTION_NOT_ACTIVE` o `PARTNER_WORKSPACE_NOT_ACTIVE`.
  </Property>
  <Property name="3 · Contrato del Art. 15 bis" type="403">
    `PARTNER_DPA_NOT_ACTIVE`.
  </Property>
  <Property name="4 · Permiso × alcance" type="403">
    `PARTNER_PERMISSION_REQUIRED` (falta el permiso en la credencial) o
    `PARTNER_SCOPE_REQUIRED` (falta el alcance en la conexión).
  </Property>
</Properties>

Entre la tercera y la cuarta se evalúa el límite de tasa, que responde `429 PARTNER_RATE_LIMITED` con `Retry-After`. El detalle de cada puerta está en [Autenticación](/autenticacion).

Si un `403` te deja con dudas, el colegio puede reproducir la evaluación completa contra tu llave con el [diagnóstico de acceso](/gestion/conexiones#diagnostico-de-acceso) (`POST /api/integrations/authorize`): la respuesta nombra la compuerta que rechazó en lugar de dejarte adivinar.

## Qué queda escrito

Cada acceso concedido y cada rechazo escriben un registro de auditoría en la organización del colegio y, cuando corresponde, un espejo en la tuya. No es un detalle de implementación: es lo que le permite al colegio acreditar ante la Agencia qué hiciste con sus datos y cuándo, y lo que te permite a ti demostrar que no hiciste nada fuera del encargo.

<div className="not-prose">
  <Button href="/inicio-rapido" variant="text" arrow="right">
    <>Ya tienes la credencial: haz tu primera solicitud</>
  </Button>
</div>