nxar.Aprender
Integraciones: hablá con otros sistemas0 de 6 capítulos
  1. 1Qué es una integración
  2. 2Tu primera integración
  3. 3Usar la respuesta en una automation
  4. 4Mandar datos a otro sistema
  5. 5Quién puede usarla
  6. 6Errores y registro de llamadas

Casos de uso

  1. ·Traer la cotización del dólar a una oportunidad
  2. ·Autenticación con bearer token
  3. ·Autenticación con usuario y contraseña (basic)
  4. ·API key en un header
  5. ·API key en la URL
  6. ·Una API que pide varios headers
  7. ·OAuth2 client credentials
  8. ·OAuth2 JWT bearer

← Volver al recorrido

Caso de uso · Integraciones: hablá con otros sistemas · 8 min

Una API que pide varios headers

Además de la clave, el servicio pide headers fijos como el código de cliente o la versión. Cómo combinar headers por default con la autenticación, y para qué sirve el tipo Headers personalizados.

Cuándo. La documentación pide más de un header en cada llamada: la clave, y además cosas como X-Cliente: <tu código> o X-Version: 2. El portal de pedidos de un proveedor de Distribuidora Del Sur funciona así.

La idea. Separás lo secreto de lo que no lo es:

  • La clave va en Autenticación, como API key en un header: se guarda cifrada.
  • Los headers fijos y no secretos van en Headers por default, uno por línea. Nxar los manda en todas las llamadas.

Para ver qué sale usamos https://httpbin.org/headers, que devuelve los headers que recibió.

Probalo en un workspace de práctica

Un workspace con el escenario ya armado, que se borra solo a las 48 h. Estamos terminándolo.

Creá la integración

ConfiguraciónIntegraciones y APIIntegrations

Nueva Integration: Etiqueta Portal de pedidos (varios headers), Nombre portal_pedidos, Método GET, URL https://httpbin.org/headers. Crear.

Headers fijos y clave

Editar. En Headers por default, escribí uno por línea, con el formato Nombre: valor:

X-Cliente: distribuidora-del-sur
X-Version: 2

En Autenticación, Tipo API key, Enviar en Header, Nombre X-Api-Key, Valor delsur-demo-key. Guardar, volvé a la lista y reabrí la integración.

Ficha en edición con Headers por default X-Cliente y X-Version, y Autenticación API key en el header X-Api-Key
Lo fijo en Headers por default; lo secreto, en Autenticación.

Probala

Ejecutar Test. En la respuesta aparecen los tres:

{
  "headers": {
    "X-Api-Key": "delsur-demo-key",
    "X-Cliente": "distribuidora-del-sur",
    "X-Version": "2"
  }
}
Test en 200 con la respuesta de httpbin mostrando X-Api-Key, X-Cliente y X-Version
Los headers por default y el de la autenticación salen juntos en cada llamada.

Los Headers por default se guardan y se muestran tal cual en la ficha, a la vista de cualquiera que la abra. No pongas ahí claves ni tokens: lo secreto va siempre en Autenticación.

¿Y el tipo Headers personalizados?

En Autenticación vas a ver también el tipo Headers personalizados. Sirve para servicios que piden dos o más headers secretos a la vez, y hoy lo usan las integraciones que instalan algunos conectores del Marketplace: el paquete define los nombres de los headers y vos sólo cargás los valores, que se guardan cifrados.

En una integración que creaste vos, si elegís ese tipo vas a ver el aviso Esta integración define sus propios nombres de header; todavía no hay ninguno para editar.: desde la pantalla no se pueden agregar nombres nuevos. Si tu servicio pide dos claves secretas, los nombres de los headers se pueden definir con la CLI de metadata (nxar), y después cargás los valores desde esta pantalla. Pedíselo a quien administra la metadata del workspace.

Cómo saber que te salió

Ejecutar Test da 200 y la respuesta lista X-Api-Key, X-Cliente y X-Version con sus valores.

¿Te funcionó?