Hoja de ruta hacia GA
La plataforma para desarrolladores de EvoMap está en beta y operativa: OAuth, OpenAPI, el modo de prueba, las APIs de recetas, las lecturas del catálogo, los webhooks, la gestión de aplicaciones y la introspección para clientes confidenciales ya se pueden usar hoy. GA significa que una persona desconocida puede autoservirse desde el sitio web, integrarse sin acompañamiento privado, operar con seguridad y recibir soporte cuando algo se rompa.
Esta página sigue la distancia entre usable en beta y plataforma abierta cualificada.
Leyenda de estados
| Estado | Significado |
|---|---|
| Disponible | Ya está a disposición de desarrolladores externos. |
| Beta | Usable, pero aún necesita ejemplos, pulido de UX o endurecimiento operativo. |
| Planificado | Falta el diseño; todavía no es una capacidad de plataforma en autoservicio. |
Matriz de capacidades para GA
| Capacidad | Estado actual | Objetivo de GA | Primera porción útil |
|---|---|---|---|
| 1. SDKs multilenguaje | Planificado | SDKs oficiales de JS/TS, Python y Go generados desde OpenAPI, más utilidades auxiliares de OAuth/webhooks escritas a mano. | Publicar la beta de @evomap/sdk con constructor de URL de OAuth, intercambio de token, lectura del catálogo, publicación de prueba, verificador de webhooks y errores con tipos. |
| 2. Consola de desarrollador unificada | Beta | Un único portal para aplicaciones, secretos, ámbitos, versiones, uso, llamadas, webhooks, entregas, concesiones, facturación y soporte. | Integrar /dev/portal en el flujo de /dev; añadir estados vacíos y de error que digan al desarrollador qué hacer a continuación. |
| 3. Revisión de aplicaciones, versiones, permisos e instalación por inquilino | Beta | Revisión de versiones de aplicación al estilo de Feishu, solicitud de ámbitos, instalación por inquilino/organización, consentimiento del administrador e historial de reversiones. | Exponer en el portal las APIs ya existentes de solicitud de ámbitos y de versiones de aplicación, con estado de revisión y registro de cambios. |
| 4. Suscripciones a eventos y repetición | Beta | Catálogo de eventos de webhook, suscripciones filtradas, ping, registro de entregas, reenvío, repetición por id de evento y política de retención. | Añadir una página de detalle de entrega de primera clase y un botón de repetición; documentar reintentos, retroceso y retención. |
| 5. Conjunto amplio de ejemplos | Beta | Guías de inicio rápido, recetas, colección de Postman/Bruno, clientes generados, verificador de webhooks, manejo de errores y demos en modo de prueba. | Publicar Ejemplos mínimos junto con proyectos de muestra descargables. |
| 6. Explorador de API | Beta | Explorador en el navegador basado en OpenAPI con utilidad de autenticación, constructor de peticiones, fragmentos de ejemplo y ocultación segura de datos sensibles. | Endurecer /dev/docs/41-api-explorer para que pueda importar un token localmente sin registrarlo y mostrar el curl/JS/Python copiado. |
| 7. Sistema de códigos de error | Beta | Catálogo de errores estable con causa, solución, si es reintentable y ruta de escalado a soporte. | Crear errors.md y enlazar todos los fallos habituales de tipo invalid_*, insufficient_scope, cuota, moderación e idempotencia. |
| 8. Marketplace | Planificado | Listado público de aplicaciones, perfil de desarrollador, instalación de aplicaciones, ámbitos mostrados antes del consentimiento, reseñas/valoraciones y flujo de retirada. | Empezar con fichas curadas de aplicaciones de partners enlazadas desde /dev, no con un listado abierto. |
| 9. Soporte y tickets para desarrolladores | Planificado | Formulario de soporte, discusión comunitaria, plantillas de incidencias, SLA de contacto y escalado para incidentes de seguridad. | Añadir /dev/support o una página de documentación con GitHub Discussions, correo/formulario y los campos de depuración obligatorios. |
| 10. Página de estado y SLA | Planificado | Estado público, historial de incidentes, objetivos de disponibilidad de la API, SLO de entrega de webhooks y avisos de mantenimiento. | Enlazar /status desde /dev y añadir filas de estado de API/webhooks específicas para desarrolladores. |
| 11. Gobernanza de permisos / autorización del administrador | Beta | Consentimiento del administrador para instalaciones en toda la organización, avisos de ámbitos de alto riesgo, revisión de mínimo privilegio y registros de auditoría. | Añadir en el portal un estado explícito de consentimiento del administrador y avisos de ámbitos de alto riesgo. |
| 12. Aislamiento por inquilino y auditoría para empresas | Beta | Claves de API delimitadas por organización/inquilino, controles de cartera y gasto, registros de auditoría, SCIM/SSO y garantías de aislamiento de datos. | Documentar los límites de agentes y tokens de organización y exponer registros de auditoría descargables para los eventos de aplicaciones OAuth. |
Qué está ya disponible
- Código de autorización de OAuth 2.0 + PKCE (solo
S256). - Descubrimiento OIDC, userinfo y JWKS.
- Metadatos del servidor de autorización OAuth y metadatos del recurso protegido.
- Registro dinámico de clientes para clientes públicos de solo lectura cuando está habilitado.
- Revocación de tokens e introspección de tokens para clientes confidenciales.
- OpenAPI 3.1 en
/openapi.jsony su réplica en YAML. - APIs de lectura de recetas / genes / reutilización.
- APIs de borrador y publicación de recetas, con modo de prueba para ciclos de publicación en el entorno de pruebas.
- Registro de aplicaciones, solicitudes de ámbitos, versiones de aplicación, registros de uso/llamadas/actividad e historial de rotación de secretos.
- Registro de webhooks, firma, ping, registros de entrega y reenvío.
- Superficies de organizaciones y tokens de agente para casos de uso de tipo empresarial.
Comprobaciones de aceptación para GA
Una versión puede llamarse GA cuando se cumple todo esto:
- Un desarrollador nuevo puede completar el inicio rápido en menos de 30 minutos sin ayuda privada.
- El primer token, la primera lectura del catálogo, la publicación de prueba, el ping de webhook y la depuración de errores tienen todos ejemplos listos para copiar y pegar.
- El portal muestra el estado de la aplicación, los ámbitos solicitados, el estado de revisión, el modo producción/prueba, las llamadas recientes, la cuota, los fallos de entrega de webhooks y las próximas acciones.
- OpenAPI, el descubrimiento, la documentación y la implementación se mantienen alineados en CI.
- Existen SDKs al menos para JS/TS y Python, con Go planificado o generado.
- Los ámbitos de alto riesgo requieren revisión explícita o consentimiento del administrador y son auditables.
- Los canales de soporte, estado, registro de cambios e incidentes son públicos y descubribles.
- Las señales de seguridad son accionables: los bucles repetidos de clientes obsoletos se deduplican para que los incidentes reales de reutilización de tokens no queden sepultados por el ruido.
Hoja de ruta a corto plazo
P0 — que cualquier desarrollador externo lo logre sin ayuda
- Mantener
/devcomo puerta de entrada pública. - Terminar el inicio rápido y los ejemplos mínimos.
- Añadir catálogo de errores y guía de resolución de problemas.
- Añadir aplicaciones de muestra descargables en Node/Python.
- Endurecer el manejo de tokens y los fragmentos del explorador de API.
P1 — que las integraciones sean operables
- Interfaz de detalle de entrega de webhooks y repetición.
- Página de soporte para desarrolladores y plantilla de incidencias.
- Filas de estado de API/webhooks y redacción del SLA.
- Estados de próxima acción en el portal para revisión de aplicaciones, solicitudes de ámbitos, cuota y webhooks fallidos.
- Guía de manejo de fallos del token de refresco (detener los bucles de reintento; forzar un nuevo inicio de sesión).
P2 — construir un ecosistema
- Paquetes de SDK.
- Listado inicial del Marketplace para aplicaciones de partners curadas.
- Flujo de instalación por inquilino/organización y consentimiento del administrador.
- Exportación de auditoría y controles de gobernanza para empresas.