# Soporte y exhaustividad de los datos

> Qué cubren y qué no cubren los datos actuales, cómo se versiona la API y cómo contactar con una persona.

Source: https://developers.backresto.com/es/docs/support

## La advertencia sobre exhaustividad, dicha sin rodeos

La API de partners expone los registros capturados **después de que la
funcionalidad se activara para ese restaurante**, en todas las
[colecciones](https://developers.backresto.com/es/docs/collections). No pretende contener el historial completo de
un restaurante, y tampoco lo va a reconstruir a posteriori. Las entregas son la
única excepción: sus dos colecciones llevan el historial que la aplicación
todavía conservaba cuando se abrieron.

Esto importa más de lo que parece:

- Un resultado vacío **no** es prueba de que no ocurriera nada. Puede
  significar que el restaurante aún no estaba activado, o que un dispositivo
  todavía no ha subido los datos.
- Un recuento de esta API no es una cifra de cumplimiento. No lo imprima en un
  informe que se lea como una auditoría.
- Si necesita saber la fecha de activación de un restaurante, pregúntenos o
  pregunte al cliente. Ahora mismo no se expone a través de la API; si la
  necesita como campo, díganoslo y pasará a serlo.

Las colecciones lo dicen en su propia respuesta: `stateKind` es
`received-shadow-snapshot`, es decir, el estado que recibió esta API, no el
estado que tiene la aplicación del restaurante. Los dos coinciden en el caso
corriente y divergen exactamente cuando un dispositivo todavía no ha subido los
datos.

Una vez activado un restaurante, los registros llegan de forma fiable, incluidos
los capturados mientras un dispositivo estaba sin conexión: esos se suben cuando
vuelve a conectarse, y por eso
[el polling incremental debe solaparse](https://developers.backresto.com/es/docs/pagination) y por eso
`capturedAt` y `receivedAt` están los dos en cada registro.

## Versionado

Todas las rutas llevan el prefijo `/v1`, y **esta API está en beta cerrada.**
Las claves se emiten a mano, a un puñado de integradores, y la forma de la API
todavía se está decidiendo. Léalo de forma literal: dentro de `/v1`, mientras
dure la beta, un endpoint puede cambiar de forma o retirarse, y no prometemos lo
contrario.

Lo que eso significa en la práctica:

- **Sea tolerante al parsear.** Ignore los campos que no conozca en lugar de
  fallar por ellos; se añaden campos a menudo.
- **Esté atento a los endpoints retirados.** Los endpoints de entregas
  dedicados, y el scope que abría sus fotografías, han desaparecido: las entregas
  se leen como [colecciones](https://developers.backresto.com/es/docs/collections), igual que cualquier otro tipo de
  registro. Véase más abajo.
- **Díganos que existe.** Sabemos qué claves nos han llamado y cuándo. Si la
  suya está en uso, nos pondremos en contacto antes de mover nada por debajo; no
  porque la beta nos obligue, sino porque romper por sorpresa una integración
  que funciona es una mala forma de llevarla.

Cuando termine la beta, esta sección pasará a ser la promesa de siempre: cambios
aditivos dentro de una versión, cualquier otra cosa detrás de `/v2`. Todavía no
es así, y decirlo le resulta más útil que una garantía que tendríamos que
retirar.

El [documento OpenAPI](https://api.backresto.com/openapi.json) se genera a partir
del servicio en ejecución, así que es la descripción de referencia de lo que está
desplegado ahora mismo. Si esta documentación y ese documento no coinciden, el
documento tiene razón y nosotros tenemos una página que corregir: díganoslo.

## Comprobaciones de estado

Dos endpoints públicos, sin autenticación:

| Endpoint | Significado |
| --- | --- |
| `GET /health/live` | El proceso está en marcha. |
| `GET /health/ready` | El proceso puede llegar a su base de datos y servir tráfico. |

`/health/ready` es el que conviene consultar si nos monitoriza. Los sondeos
correctos no se registran en la auditoría, así que un monitor no añade ruido.

## Conseguir ayuda

Escriba a [contact@backresto.com](mailto:contact@backresto.com). Lo que hace que
una respuesta sea rápida:

- el `requestId` del documento de problema, o el `X-Request-ID` que envió;
- el **prefijo público** de su clave (la mitad `brp_…` anterior al punto, nunca el
  secreto);
- el entorno, el endpoint y, aproximadamente, cuándo.

Nunca nos envíe el secreto de una clave: el prefijo público la identifica sin
ambigüedad. Si un secreto ha ido a parar donde no debía, dígalo en el asunto y
envíe el prefijo: la revocación es inmediata, y es el remedio completo. Consulte
[Obtener una clave](https://developers.backresto.com/es/docs/access) para el resto del ciclo de vida de una clave.

## Pedir más

Lo que existe aquí existe porque alguien lo pidió. Las temperaturas de cocción y
enfriamiento, los planes de limpieza, las etiquetas y un endpoint MCP alojado
estaban todos en esta lista hace unos meses; ahora son
[colecciones](https://developers.backresto.com/es/docs/collections) y [un endpoint](https://developers.backresto.com/es/docs/mcp).

**Las entregas eran lo último de esta lista.** Fueron lo primero que sirvió esta
API, a través de sus propios endpoints, con su propia forma y un rango de tiempo
en lugar de un cursor. Ahora son dos colecciones, `deliveries` y
`delivery-pictures`, que se leen con el mismo sobre, la misma paginación y el
mismo `GET .../collections/{collection}/records` que cualquier otro tipo de
registro, y los antiguos endpoints se retiran en lugar de mantenerse al lado.
Una sola manera de leer un registro es el sentido del cambio. Si construyó sobre
los antiguos endpoints, [Entregas](https://developers.backresto.com/es/docs/deliveries) muestra la nueva forma, y
le ayudamos con gusto a migrar.

Lo que sigue en ella: webhooks en lugar de polling, un cursor incremental en
las colecciones, una fecha de activación en el restaurante, y el inicio de
sesión OAuth para los clientes MCP que no aceptan una clave. Cuál viene después
lo decide quién lo pide. Así que pídalo.