Apex Academy
Módulo 11·03·25 min

Named Credentials y Remote Site Settings

Salesforce no deja llamar a una dirección que el Admin no haya autorizado. Una Named Credential guarda en Setup la dirección y la forma de autenticarse; el código solo escribe callout:Nombre, y ninguna clave vive en el código.

En Admin esUn usuario de integración que configura el Admin: el código solo lo nombra

✓ En esta sub-lección

  1. 01Explicar por qué un callout a una URL sin autorizar falla.
  2. 02Usar una Named Credential en lugar de una URL y una clave escritas en el código.
  3. 03Entender por qué eso hace el código igual en sandbox y en producción.

La nutria: ¿Te acuerdas? · Repaso de la lección 2

El JSON del ERP trae un nombre que tu clase molde no tiene. ¿Qué pasa al deserializar?

Revisando el código del puente encuentras el cliente de la API de impuestos, de un compañero: la dirección escrita a mano y, en la línea siguiente, la clave de producción en una cabecera. Cualquiera con acceso al código la puede leer, está copiada en el repositorio para siempre, y en la sandbox ese código llama al sistema de verdad.

Salesforce no llama a cualquier sitio

Por seguridad, un callout a una dirección que nadie ha autorizado falla con «Unauthorized endpoint». Hay dos formas de autorizarla. La antigua es Setup → Remote Site Settings: una lista de direcciones permitidas, y nada más; la clave seguiría en el código. La buena es una : autoriza la dirección y además guarda cómo autenticarse.

Apex
// Antes: dirección y clave a la vista
req.setEndpoint('https://tax.partner-northwind.com/v2/rates/' + country);
req.setHeader('Authorization', 'Bearer clave-de-produccion-1234');

// Después: el código solo nombra la credencial
req.setEndpoint('callout:Tax_API/v2/rates/' + country);
callout:Tax_API se sustituye por la dirección guardada en Setup, y Salesforce añade la autenticación al enviar. El resto de la ruta se escribe detrás, como siempre.
Estás en:

  • ¿Qué se ve en el código?

    la dirección y la clave, para cualquiera que lo abra

  • ¿A dónde llama este entorno?

    al sistema de producción, siempre

  • ¿Cambiar la clave?

    cambiar el código y desplegar, con tests

En la sandbox, este código llama al sistema de producción con la clave de producción.

Compara las dos formas: qué se ve en el código, a dónde llama cada entorno y qué hay que hacer para cambiar la clave.
  • La clave no está en el código ni en el repositorio: vive cifrada en Setup, y quién puede usarla se decide con un permission set.
  • El mismo código sirve en todos los entornos: en la sandbox, la credencial apunta al sistema de pruebas; en producción, al de verdad.
  • Cambiar la clave es una tarea de Admin en Setup, sin tocar código ni desplegar.

La nutria: Esto lo configuras tú mejor que nadie

Aquí el Admin que llevas dentro tiene ventaja: una Named Credential se crea en Setup → Named Credentials, junto con su External Credential (que guarda la autenticación) y un permission set que da acceso. Es configuración, no código. En muchos equipos, el developer escribe callout:Tax_API y es el Admin quien la deja lista en cada entorno.

La nutria: ¿Y por qué no un Flow? Aquí Flow te obligaba a hacerlo bien

Te lo reconozco: la acción HTTP Callout de un flow no te deja escribir una dirección ni una clave; te pide una Named Credential desde el primer paso. En Apex nadie te obliga, y por eso aparece código como el de mi compañero. La regla es la misma en los dos mundos, solo que aquí la disciplina la pones tú.