Conectar una app Flutter a una API propia en producción

Flutter es la app que instalas en el móvil. La API es un servicio separado al que esa app envía peticiones para iniciar sesión, leer o guardar datos. Publicar la app en Google Play o App Store no publica esa API: también necesitas desplegar el backend en una dirección pública y probar la versión instalada.

Esta guía cubre el lado Flutter del enlace y qué debe estar listo en el servidor. Si aún estás eligiendo dónde ejecutar tu servicio, compara Projects y VPS para el backend de una app móvil. Si estás comparando servicios gestionados con código servidor propio, lee Firebase o backend propio para una app. Para problemas de una API que funciona localmente pero falla publicada, consulta cómo diagnosticar llamadas de frontend a una API en producción.

1. Sustituye localhost por una dirección accesible

localhost siempre significa «este mismo dispositivo». En el ordenador apunta al ordenador; en un teléfono apunta al teléfono. Por eso una petición que funciona en el navegador del desarrollador puede fallar al instalar la app en un móvil.

En producción utiliza el nombre público de tu API, con HTTPS, por ejemplo https://api.ejemplo.com. Comprueba que el DNS resuelve, que el certificado es válido y que la ruta devuelve el formato esperado. No desactives las comprobaciones TLS para ocultar un error de certificado.

Durante el desarrollo, un emulador puede necesitar una dirección especial para llegar al ordenador anfitrión; un teléfono físico puede necesitar una dirección accesible en la red local. Esos valores de desarrollo no deben colarse en el build de producción. Verifica la URL que lleva la app que vas a publicar.

2. Añade el cliente HTTP y configura la URL

La guía oficial de Flutter recomienda el paquete http para peticiones web y muestra cómo transformar una respuesta JSON en un objeto de Dart. Añádelo con flutter pub add http y centraliza la URL base para no repetirla en cada pantalla. Receta oficial de Flutter

Puedes proporcionar una URL distinta para desarrollo y producción al compilar. Por ejemplo, --dart-define=API_BASE_URL=https://api.ejemplo.com permite leer un valor no secreto desde String.fromEnvironment. Ese valor queda dentro de la app compilada y cualquiera puede inspeccionarlo: sirve para configurar la dirección pública, no para esconder contraseñas, claves privadas o credenciales de administrador.

Un cliente pequeño puede comprobar tanto el estado HTTP como el JSON antes de entregar datos a la interfaz:

import 'dart:convert';
import 'package:http/http.dart' as http;

const apiBaseUrl = String.fromEnvironment('API_BASE_URL');

Future<Map<String, dynamic>> fetchProfile(String accessToken) async {
  final uri = Uri.parse('$apiBaseUrl/v1/profile');
  final response = await http.get(
    uri,
    headers: {'Authorization': 'Bearer $accessToken'},
  );

  if (response.statusCode < 200 || response.statusCode >= 300) {
    throw Exception('La API respondió HTTP ${response.statusCode}');
  }

  final contentType = response.headers['content-type'] ?? '';
  if (!contentType.contains('application/json')) {
    throw const FormatException('La respuesta no es JSON');
  }

  final decoded = jsonDecode(response.body);
  if (decoded is! Map<String, dynamic>) {
    throw const FormatException('La respuesta no tiene el formato esperado');
  }
  return decoded;
}

El ejemplo supone que el usuario ya inició sesión y que el backend emite un token de acceso. No implementa el inicio de sesión, el almacenamiento seguro del token, la renovación, el manejo visual de errores ni la forma completa del perfil: adáptalo al contrato real de tu API.

3. No incluyas secretos dentro de la aplicación

Una app móvil se distribuye a los dispositivos de otras personas. Una clave que viene en el código o en el binario puede extraerse. No pongas ahí una clave de servicio, contraseña de base de datos, token de administrador ni secreto que permita saltarse los permisos.

El backend debe autenticar cada petición y comprobar qué puede hacer ese usuario sobre ese recurso. No basta con ocultar un botón o una pantalla. Usa HTTPS, valida entradas, limita intentos y registra errores sin guardar tokens ni datos privados. La guía de seguridad REST de OWASP explica controles como restringir métodos, devolver errores apropiados y tratar con cuidado las claves de API.

4. Asegúrate de que el servidor responde como la app espera

Prueba primero una ruta de solo lectura como /healthz o /v1/status con un cliente HTTP. Comprueba DNS, TLS, código de estado, Content-Type y cuerpo. Después haz la misma petición desde la app instalada, tanto en Android como en iOS. Simula una respuesta 401, una caída de red y una respuesta mal formada: la interfaz debe mostrar un error recuperable, no quedarse cargando para siempre.

En las llamadas nativas de Flutter no configures CORS como solución genérica: CORS es una política que aplica el navegador. Si también tienes una versión web de Flutter, el navegador sí puede hacer una preflight y necesitar cabeceras CORS en el servidor. Identifica primero si la petición viene de una app nativa o de Flutter Web.

5. Elige el lugar donde corre el backend

Si tu API es un servicio Node.js o un contenedor que Projects admite, revisa los recursos del plan y su forma de despliegue antes de conectarlo al dominio. Si necesitas controlar paquetes del sistema, varios servicios, Docker Compose o el proxy, un VPS te da más control, pero tú administras el sistema, los parches, las copias y la seguridad.

Hostbrid aloja el servidor/API; la publicación del binario en las tiendas, la lógica de autenticación, la base de datos y el diseño de copias de seguridad dependen de tu aplicación y de los servicios que elijas. Mira los VPS de Hostbrid y la guía de API móvil en Projects o VPS antes de contratar.

Lista de comprobación antes de enviar el build a las tiendas

• La URL del build apunta a una API HTTPS pública, no a localhost ni a una IP de desarrollo.
• El certificado y el DNS funcionan desde una red externa.
• La API devuelve estados y JSON que el cliente sabe interpretar.
• El backend valida identidad, permisos y datos en cada petición.
• No hay claves privadas ni credenciales de administrador en el código Flutter.
• Las pruebas incluyen Android y iOS, errores HTTP y una conexión sin red.

Referencias: Flutter: Fetch data from the internet, Flutter networking cookbook, OWASP REST Security Cheat Sheet.