Saltar al contenido

Autenticación

Dos formas de autenticarse, ambas vinculadas a su ID de clave: solicitudes firmadas (recomendado) o tokens Bearer de OAuth 2 con credenciales de cliente.

  1. Solicitudes firmadas (HMAC-SHA256)
  2. Credenciales de cliente de OAuth 2
  3. ID de clave, secretos y rotación
  4. Lista de IP permitidas

Solicitudes firmadas (HMAC-SHA256)

Envíe X-API-Key, X-Timestamp, X-Nonce y X-Signature en cada llamada. La firma cubre el método, el destino exacto de la solicitud (ruta y query), el timestamp, el nonce y el hash del cuerpo, de modo que una solicitud repetida o alterada no supera la verificación. Se tolera un desfase de reloj de hasta cinco minutos; la reutilización de un nonce en menos de diez minutos se rechaza con 401 api_nonce_reused.

Calcule la firma sobre los bytes exactos que envía. Serialice su JSON una sola vez, calcule el hash de esos mismos bytes y envíelos tal cual como cuerpo: volver a serializar después de firmar es la causa más habitual de api_signature_invalid.

Node.js
const payload = JSON.stringify(body);
const ts = Math.floor(Date.now() / 1000);
const nonce = randomBytes(16).toString("hex");
const bodyHash = createHash("sha256").update(payload).digest("hex");
const canonical = ["POST", "/v1/flights/search", ts, nonce, bodyHash].join("\n");
const signature = createHmac("sha256", SECRET).update(canonical).digest("hex");

Credenciales de cliente de OAuth 2

Si firmar cada solicitud no encaja en su stack, intercambie su ID de clave y su secreto por un token Bearer de corta duración en POST /v1/oauth/token (grant_type=client_credentials, codificado como formulario). Los tokens duran 30 minutos y llevan los ámbitos que tiene concedidos; puede solicitar un subconjunto con el parámetro scope.

Envíe el token como Authorization: Bearer junto con X-API-Key en cada llamada. El ID de clave se vuelve a comprobar en cada solicitud, así que revocar una clave invalida sus tokens de inmediato.

cURL
curl -X POST "https://api.dubaitrip.com/v1/oauth/token" \
  -d grant_type=client_credentials -d client_id=$KEY_ID -d client_secret=$SECRET

ID de clave, secretos y rotación

Las claves de sandbox empiezan por dt_sbx_ y las de producción, por dt_live_. Cada clave pertenece a un entorno y a un socio. Los secretos se muestran una sola vez (al crearlos, al rotarlos y mediante el enlace de revelación) y se almacenan solo como hash en nuestros sistemas.

Rote las claves desde el portal para desarrolladores: se emiten un nuevo ID de clave y un nuevo secreto mientras la clave antigua sigue funcionando durante el periodo de gracia que elija (hasta siete días), para que pueda hacer el cambio sin interrupciones. La revocación es inmediata.

Lista de IP permitidas

Opcionalmente, restrinja cada entorno a un conjunto de direcciones IPv4/IPv6 o rangos CIDR en el portal para desarrolladores. Las solicitudes desde cualquier otra dirección se rechazan con 403 api_ip_not_allowed aunque estén correctamente firmadas. Deje la lista vacía para aceptar cualquier origen.