Soporte y exhaustividad de los datos

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. 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 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, 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 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:

/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. 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 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 y un endpoint.

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 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.