1. Autenticación
Hay dos endpoints, con el mismo comportamiento y distinta credencial. Elegí uno según el caso.
| Endpoint | Credencial | Cuándo usarlo |
|---|---|---|
/jwt-odata-key/ | header X-API-Key | Integraciones servidor a servidor y herramientas de BI. Es el más simple: una sola credencial de larga duración, sin login previo. |
/jwt-odata/ | Authorization: Bearer | Cuando hace falta que las operaciones queden a nombre de un usuario del ERP. Requiere un login previo y el token vence a las 12 horas. |
Con API key
curl -s -H "X-API-Key: TU_API_KEY" \
'https://TU-HOST/synergy-server/jwt-odata-key/o_customers?$top=1'
Con JWT
Primero el login. El id_client identifica tu integración y queda firmado dentro del token.
curl -s -X POST -H "Content-Type: application/json" \
-d '{"user":"integrador","password":"...","id_client":"MI_INTEGRACION"}' \
'https://TU-HOST/synergy-server/jwt-odata?type=token'
{ "token": "eyJhbGciOiJIUzI1NiJ9...", "id_client": "MI_INTEGRACION" }
Después, en cada request:
curl -s -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9..." \
'https://TU-HOST/synergy-server/jwt-odata/o_customers?$top=1'
- Vida del token: 12 horas — Pasado ese plazo todo request responde
403 TokenExpiredy hay que volver a hacer login. No hay refresh token. - El
id_clientva firmado — Se resuelve en el login, no en cada request. Si el administrador cargóm_jwt_clients.user_idpara tu usuario podés omitirlo en el body; si no, es obligatorio. Un login que no puede resolverlo responde400con el detalle, en vez de devolver un token que después falla.
Lista blanca de IP
Cada cliente puede tener una lista de direcciones autorizadas. Si la credencial es correcta pero recibís 403 IpNotAllowed, el problema es la IP de salida, no la clave.
| Formato | Ejemplo |
|---|---|
| IP exacta (v4 o v6) | 10.0.0.1, 2001:db8::1 |
| Rango CIDR | 10.0.0.0/8, 2001:db8::/32 |
| Comodín por octeto (solo IPv4) | 10.0.0.*, 192.168.* |
| Cualquiera | * |
Se separan por comas, punto y coma o espacios. Lo que compara el servidor es la dirección del par TCP, no el header X-Forwarded-For: si tu tráfico sale por un proxy o un NAT, la que hay que autorizar es la IP del proxy. Una regla IPv4 nunca coincide con un cliente que llega por IPv6 y viceversa.