> For the complete documentation index, see [llms.txt](https://docs.blerify.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.blerify.com/es/introduccion-a-la-verificacion/reference/reference-implementation.md).

# Implementación de Referencias

El `blerify-verification-demo` es una implementación de referencia desplegable del patrón de integración de verificación de Blerify. Es una aplicación del lado del servidor en Next.js que demuestra el flujo completo: autenticar una cuenta de servicio, iniciar una sesión de verificación, mostrar al usuario un código QR o un botón de billetera y consultar periódicamente el resultado. Ningún secreto sale del servidor.

Úsalo como un ejemplo funcional para entender la integración antes de crear la tuya, o haz un fork de él como punto de partida para una implementación real.

El código fuente está en [github.com/BlerifyPlatform/blerify-verification-demo](https://github.com/BlerifyPlatform/blerify-verification-demo). Las instrucciones de compilación, la configuración del desarrollo local y el código fuente completo están en el README de ese repositorio; esta página cubre los requisitos del Portal, la configuración y los destinos de despliegue.

***

## Requisitos previos

* Una cuenta de Blerify con acceso de propietario o administrador de la organización
* Un proyecto de verificación en el Portal
* Los dos artefactos del Portal descritos abajo: una cuenta de servicio y una plantilla de verificación publicada

***

## Cómo funciona

La demo es un Backend para frontend (BFF). Tu navegador nunca almacena credenciales ni llama a Blerify directamente.

```
Navegador  ──POST /api/start──▶  BFF  ──iniciar la sesión──▶  Blerify
  │   muestra QR o botón de billetera  ◀──  { transaction_id, ... }
  │
Billetera  ── escanea el QR o abre un enlace profundo, presenta la credencial ──▶  Blerify
  │
  └─  GET /api/status?transactionId  ──▶  BFF  ──consultar resultado──▶  Blerify
                                     ◀──  { status, claims de la credencial }
```

El BFF se autentica en Blerify usando una cuenta de servicio con `private_key_jwt` (RFC 7523). La billetera se comunica con Blerify directamente: el BFF nunca forma parte de la ruta de transporte de la credencial. El resultado regresa mediante sondeo, vinculado a `transaction_id`.

En móviles, la demo detecta el agente de usuario y muestra un botón de billetera en lugar de un código QR. Un interruptor permite a los usuarios cambiar a QR si su billetera está en otro dispositivo.

Para ver el detalle completo del protocolo — endpoints, esquemas de solicitud/respuesta, estados de sesión — consulta las [Referencias de la API](https://dev.blerify.com).

***

## Paso 1 — Crear una cuenta de servicio

La cuenta de servicio es la forma en que el BFF se autentica en Blerify de máquina a máquina. La creas a nivel de organización y necesitas acceso de propietario o administrador de la organización.

1. En el Portal, ve a **Organization → Service Accounts** y haz clic en **Create service account**.
2. Completa un nombre y una descripción.
3. En **Signing algorithm**, selecciona `RS256`.
4. En **Roles**, selecciona **Verifications** — esto le concede a la cuenta permiso para iniciar y consultar sesiones de verificación.
5. En **Project**, elige el proyecto de verificación donde vive (o vivirá) tu plantilla.
6. Haz clic en **Create**. El Portal genera un par de claves y te pide descargar un archivo JSON de credenciales.
7. **Descarga el archivo ahora.** La clave privada se muestra una sola vez y no se puede recuperar otra vez. El botón de descarga permanece activo hasta que cierres el diálogo; ciérralo solo después de guardar el archivo.

El JSON descargado contiene todo lo que la demo necesita para autenticarse:

| Campo JSON        | Variable de entorno             |
| ----------------- | ------------------------------- |
| `client_id`       | `SA_CLIENT_ID`                  |
| `private_key`     | `SA_PRIVATE_KEY`                |
| `iam_audience`    | `SA_IAM_AUDIENCE`               |
| `token_uri`       | `SA_TOKEN_URI` (opcional)       |
| `organization_id` | `SA_ORGANIZATION_ID` (opcional) |

***

## Paso 2 — Crear y publicar una plantilla de verificación

Una plantilla de verificación define qué credencial solicitar, en qué emisor confiar y qué nivel de aseguramiento exigir. Se encuentra dentro de un proyecto de verificación.

1. Abre el proyecto de verificación y ve a **Reglas de verificación → Nueva regla**.
2. Elige un nivel de aseguramiento y los tipos de credencial que aceptar. Esto abre un asistente de cinco pasos:
   * **Información** — nombre, código interno, descripción, tipo
   * **Atributos y pruebas** — qué reclamaciones solicitar de cada credencial
   * **Verifications** — configuración de validación y transporte (OpenID4VP)
   * **Listas de sanciones** — listas de control opcionales
   * **Integración técnica** — selecciona la cuenta de servicio que creaste en el Paso 1 y luego genera el ID de la regla
3. En el **Integración técnica** paso, haz clic en **Generar ID** para guardar la regla como borrador, luego haz clic en **"Publish rule"** para activarla. Solo una regla publicada puede usarse en tiempo de ejecución.

**Cómo encontrar tus IDs.** El **Integración técnica** El paso muestra un fragmento de código con la ruta completa del endpoint. Esa ruta contiene los tres IDs que necesitas:

```
.../organizations/{ORG_ID}/projects/{PROJECT_ID}/verifications/{RULE_ID}
```

Cópialos desde allí. `RULE_ID` es el UUID etiquetado como **"Rule ID"** en el paso de integración — no el `ver_…` identificador mostrado en la pantalla de detalles de la regla.

***

## Paso 3 — Configura la demo

Toda la configuración es en tiempo de ejecución — nada se incorpora en el artefacto de build. Copia `.env.example` del repositorio y establece los valores para tu entorno:

| Variable             | Descripción                                                                                                 |
| -------------------- | ----------------------------------------------------------------------------------------------------------- |
| `BLERIFY_API_URL`    | URL base de la API de Blerify para tu entorno                                                               |
| `ORG_ID`             | Tu ID de organización                                                                                       |
| `PROJECT_ID`         | Tu ID de proyecto de verificación                                                                           |
| `RULE_ID`            | El UUID de tu plantilla de verificación publicada                                                           |
| `WALLET_BASE_URL`    | URL base de la Blerify Wallet                                                                               |
| `SA_CLIENT_ID`       | Desde el JSON de la cuenta de servicio                                                                      |
| `SA_PRIVATE_KEY`     | Desde el JSON de la cuenta de servicio (PEM, PKCS#8, RSA-2048)                                              |
| `SA_IAM_AUDIENCE`    | Desde el JSON de la cuenta de servicio                                                                      |
| `SA_TOKEN_URI`       | Opcional — usa de forma predeterminada el endpoint de token Estándar                                        |
| `SA_ORGANIZATION_ID` | Opcional — el valor predeterminado es `ORG_ID`                                                              |
| `DEMO_MOCK`          | Establece en `true` para ejecutar toda la interfaz de usuario sin un backend real ni una cuenta de servicio |

`DEMO_MOCK=true` te permite explorar la interfaz de usuario y simular el flujo completo sin configurar credenciales de Blerify. Úsalo para evaluar la interfaz antes de configurar los requisitos previos del Portal.

***

## Deploying

La misma base de código se deploya a tres destinos. En todos los casos, configura las variables de entorno en la plataforma — nunca hagas commit de ellas en el repositorio.

### Netlify

Conecta el repositorio en el dashboard de Netlify. El `netlify.toml` en el repositorio declara el comando de build y configura el adaptador de Next.js, que sirve las rutas de API como funciones sin servidor. Define las variables de entorno en **Configuración del sitio → Variables de entorno**.

### Vercel

Importa el repositorio en el dashboard de Vercel. Vercel lo detecta automáticamente como un proyecto de Next.js usando `vercel.json`. Define las variables de entorno en la configuración del proyecto.

### Docker

```bash
docker build -t blerify-verification-demo .
docker run --env-file .env -p 8080:8080 blerify-verification-demo
```

La imagen es genérica — lee toda la configuración de las variables de entorno al iniciarse. Usa la misma imagen en todos los entornos cambiando el archivo de variables de entorno, no la imagen.

El pipeline de CI del repositorio valida cada envío: verificación de tipos, build y construcción de imágenes de Docker. No hace deploy y no requiere secretos.

***

## Próximos pasos

**Continúa con** [**Empezar**](/es/introduccion-a-la-verificacion/build/get-started.md) — construye el mismo flujo que implementa esta demo, paso a paso.

Ver también: [Leer un resultado de verificación](/es/introduccion-a-la-verificacion/build/read-a-verification-result.md) · [niveles de garantía](/es/introduccion-a-la-verificacion/learn/assurance-tiers.md) · [Referencias de la API](https://dev.blerify.com)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.blerify.com/es/introduccion-a-la-verificacion/reference/reference-implementation.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
