Las APIs de iFood utilizan autenticación OAuth 2.0 con tokens Bearer. Para acceder a los recursos de la API:
Obtén un token de acceso para tu aplicación
Incluye el token en el header de Authorization de cada petición
Usa el formato: Authorization: Bearer YOUR_ACCESS_TOKEN
curl --location 'https://merchant-api.ifood.com.br/authentication/v1.0/oauth/token' \--header 'accept: application/json' \--header 'Content-Type: application/x-www-form-urlencoded' \--data-urlencode 'grantType=client_credentials, authorization_code, OR refresh_token' \--data-urlencode 'clientId=YOUR_CLIENT_ID' \--data-urlencode 'clientSecret=YOUR_CLIENT_SECRET' \--data-urlencode 'authorizationCode=It is only required when using the authorization code flow' \--data-urlencode 'authorizationCodeVerifier=It is only required when using the authorization code flow' \--data-urlencode 'refreshToken=It is only required when using the refresh_token grantType'
Requisitos de seguridad
Usa únicamente HTTPS con TLS 1.2 o superior
Peticiones HTTP serán rechazadas
Peticiones sin autenticación serán rechazadas
Obtener token de acceso
El proceso para obtener un token de acceso varía dependiendo del tipo de tu aplicación (centralizada o distribuida). Sigue nuestras guías paso a paso para implementar el flujo más adecuado para tu aplicación:
Para más informaciones sobre aplicaciones centralizadas o distribuidas consulta aquí nuestra documentación.
Actualización de tokens después de nuevos permisos
Solicita un nuevo access_token cuando tu aplicación reciba un nuevo permiso de algún merchant. Este token incluirá los permisos para todos los merchants autorizados.
Verifica los permisos (opcional)
Para tener certeza que los permisos de acceso al nuevo merchant están válidos, sigue los siguientes pasos:
Asegúrate que tu aplicación tenga permiso en el módulo merchant
Verifica si el nuevo merchant aparece en la lista retornada
Esta verificación confirma que tu access_token tiene los permisos correctos para el merchant recién agregado.
Siempre que tu aplicación recibe un nuevo permiso de algún merchant, es necesario solicitar un nuevo token para que tu nuevo access_token tenga permiso en ese merchant recién agregado.
Tiempo de propagación de nuevos permisos
Cuando un nuevo permiso es autorizado/revocado, puede demorar hasta 10 minutos para que ese dato sea propagado para toda la plataforma. Caso el nuevo merchant aún no sea retornado en el listado de merchants sugerido arriba, espera 10 minutos y genera un nuevo access_token. Estamos trabajando para reducir ese tiempo y en breve disponibilizaremos esa mejora.
Gestión de códigos y tokens
Tiempos de expiración pueden cambiar
Implementa la renovación de tokens basada en el valor expiresIn recibido en la respuesta de la API. Nunca dependas de tiempos fijos, pues podemos alterar los períodos de expiración en cualquier momento.La tabla abajo presenta los tiempos de expiración por defecto de cada token y código:
Código/Token
Expiración
Token de acceso
3 horas
Refresh token
168 horas
Código de vínculo
10 minutos
Código de autorización
5 minutos
Buenas prácticas
Programa renovaciones automáticas basadas en el expiresIn recibido con el accessToken
Prepara tu aplicación para solicitar un nuevo token cuando reciba status 401
Validez y renovación
Los tokens y códigos funcionan únicamente durante su período de validez. En casos de:
Códigos expirados: Solicita nuevos códigos
Token de acceso expirados: Usa el refresh token para obtener un nuevo token de acceso
Refresh tokens expirados: Solicita un nuevo token completo vía API de Autenticación.
Rate Limit
Evita exceso de solicitudes. No generes un nuevo token antes de la expiración del actual. Solicitudes excesivas pueden resultar en bloqueo de tu aplicación.
Identifica tokens expirados
Cuando un token de acceso expira, las APIs retornan status 401. Este código indica que debes renovar el token antes de continuar.
¿Esta página fue útil?
Evalúa tu experiencia en el nuevo portal de desarrolladores: