Envía leads a NetSuite

NetSuite es la única conexión de aquí que firma cada petición en vez de llevar un token. Su autenticación por token es OAuth 1.0a: cinco valores que creas una vez dentro de NetSuite, y una firma que se calcula en cada llamada a partir del método, la URL y los parámetros.

Nada de esto caduca por reloj, y no hay nada que refrescar.

Qué necesitas

Dos funciones activadas, dos registros creados, cinco valores apuntados.

En Setup, Company, Enable Features, SuiteCloud, marca Token-Based Authentication y REST Web Services.

Después:

• Un registro de integración (Setup, Integration, Manage Integrations, New) con la autenticación por token marcada. Te da una clave de consumidor y un secreto de consumidor, que se muestran una sola vez.
• Un token de acceso (Setup, Users/Roles, Access Tokens, New) para el rol que va a crear los registros. Te da un id de token y un secreto de token, también de una sola vez.
• Tu id de cuenta, en Setup, Company, Company Information. Un sandbox se parece a 1234567_SB1.

Si se te escapó uno de los valores que se muestran una vez, la solución es crear otro. NetSuite no lo vuelve a enseñar, y nosotros tampoco.

Cuentas sandbox

Un sandbox responde en su propio host, que sale del id de cuenta: 1234567_SB1 se convierte en 1234567-sb1.suitetalk.api.netsuite.com. No tienes que calcularlo -- pega el id tal y como lo escribe NetSuite y el host sale solo.

Conectar y enrutar

1. En Destinos, conecta NetSuite con el id de cuenta y los cuatro valores. Verificamos con una lectura, que prueba los cinco valores, la firma y el rol a la vez.
2. Elige el tipo de registro: Cliente, Contacto u Oportunidad.
3. Crea una ruta -- qué leads coge y en qué registro se convierten.
4. Mapea los campos. Salen del esquema del propio tipo de registro, así que lo que ves es lo que tu cuenta va a aceptar.

Lead o cliente

En NetSuite un lead no es un tipo de registro aparte. Es un cliente en una fase temprana, con un estado que avanza según avanza la relación. Crear el cliente es crear el lead; la fase la pones tú en NetSuite.

Qué se envía

Solo campos escribibles del esquema del registro. Los campos que guardan otro registro -- una subsidiaria, un comercial, una moneda -- se quedan fuera del mapeador, porque quieren el id interno de ese registro y un texto escrito en un chat no lo es.

Los valores se adaptan al campo. Un campo numérico se queda con los dígitos de lo que escribió el visitante. Una casilla entiende sí, no, true, false, 1 y 0. Una fecha se convierte en AAAA-MM-DD.

Un cliente necesita nombre. Se rellena con lo que traiga el lead cuando el mapeo lo deja fuera, como persona y no como empresa, así que una ruta nunca pierde un lead por un campo en blanco.

Una fecha que conviene saber

La documentación de Oracle dice que desde 2027.1 no se podrán crear integraciones nuevas con autenticación por token para los servicios web REST. Las existentes siguen funcionando. Una conexión hecha hoy no se ve afectada; una hecha tras esa versión necesitará OAuth 2.0, que en NetSuite significa una aserción firmada y un certificado en vez de un secreto. Lo soportaremos antes de que haga falta.

Errores habituales

INVALID_LOGIN_ATTEMPT cubre casi todo: un valor mal, un token emitido para otra cuenta, o una firma que no cuadró. No dice cuál, y es a propósito. Revisa primero el id de cuenta -- es el valor que más gente pega con las mayúsculas o el separador equivocados.

Un error de permisos en vez de uno de inicio de sesión significa que los cinco valores están bien y que el rol que lleva el token no puede crear ese tipo de registro.

Qué no hace

Crea. No actualiza un registro existente y no deduplica. Los tipos de registro personalizados todavía no se ofrecen.