API de Feending

Tu organización puede conservar sus herramientas y su forma de trabajar. La integración convierte la información de un sistema al formato que entiende el otro.

1. Tu equipo conecta directamente con la API

Vuestros desarrolladores preparan los datos en el formato de Feending y los envían a su API. También reciben los avisos de Feending o consultan sus cambios para actualizar vuestro sistema. Esta vía encaja cuando tenéis una aplicación propia o un equipo que mantiene la conexión.

Responsabilidad: vuestro equipo desarrolla y mantiene la transformación, las credenciales y el tratamiento de errores. Feending proporciona el contrato de su API y de sus eventos.

2. Una herramienta intermedia conecta ambos sistemas

Un servicio de integración se sitúa entre vuestra herramienta y Feending. Algunos ejemplos conocidos son Microsoft Power Automate, Make, Zapier y n8n. Recibe un cambio, convierte los campos y llama al sistema de destino. Por ejemplo, un flujo puede recoger un cambio de departamento en vuestra herramienta de personal y actualizar la cuenta correspondiente en Feending.

Responsabilidad: quien gestiona ese servicio configura las conexiones, mantiene las reglas y supervisa los fallos. Esta vía necesita que la herramienta pueda utilizar las operaciones y la autenticación de ambos sistemas. Estas plataformas pueden utilizar llamadas a la API; la conexión requiere configurar el flujo y no presupone que exista un conector de Feending en su catálogo.

3. Feending desarrolla un conector para vuestro sistema

Cuando necesitáis conservar un formato o un proceso particular, se puede desarrollar un conector que se encargue de traducirlo y comunicarse con Feending. Su alcance se concreta para el sistema y las operaciones que se van a conectar.

Responsabilidad: se acuerda quién aloja, mantiene y supervisa el conector. El cliente facilita la documentación y los accesos de su sistema. Un conector específico requiere configuración o desarrollo; no debe darse por disponible para cualquier producto.

Las tres vías pueden trabajar en ambos sentidos. En todas hay que establecer qué datos se comparten y qué sistema decide el valor de cada campo.

Un sistema puede llamar «nombre del empleado» a lo que otro llama «nombre». La conexión establece esa correspondencia para que ambos hablen de la misma persona y del mismo dato.

De tu sistema a Feending

RR. HH. cambia el departamento de Ana. Vuestro código, la herramienta intermedia o el conector detecta el cambio, localiza su cuenta y solicita la actualización a la API de Feending. No hace falta que RR. HH. cambie sus nombres de campos.

De Feending a tu sistema

Ana modifica un dato cuyo mantenimiento corresponde a Feending. La integración recibe el aviso o consulta el cambio y lo convierte al formato que exige vuestro sistema para actualizarlo. Para hacerlo, ese sistema debe permitir recibir la modificación.

Quién decide qué dato prevalece

Por ejemplo, RR. HH. puede ser responsable del departamento y Feending de determinados datos del perfil de comunidad. La conexión respeta ese reparto, evita devolver un cambio a su origen repetidamente y registra los errores para poder recuperarlos.

Antes de activar la conexión deben quedar definidos los datos, las direcciones, las correspondencias entre registros y la persona o equipo que atenderá los fallos. Podéis combinar vías: acceso desde vuestra aplicación y sincronización de perfiles mediante un servicio intermedio.

El acceso delegado permite continuar en Feending desde un portal que ya ha autenticado a la persona.

Ejemplo: una organización utiliza Microsoft Entra ID

1. La persona accede al portal corporativo. La organización comprueba su identidad mediante su sistema habitual, incluidas las condiciones de acceso que tenga configuradas.
2. Elige entrar en Feending. El servidor del portal comprueba que tiene autorización y relaciona su identidad con la cuenta de Feending.
3. El portal solicita un acceso temporal. Utiliza la credencial de integración, guardada en el servidor. Feending devuelve un enlace con un token válido durante cinco minutos.
4. La persona llega a Feending. La aplicación valida el enlace y las condiciones de su cuenta. No necesita introducir una contraseña de Feending.

Qué está disponible y qué debe conectarse

Feending ya puede generar y validar esos enlaces temporales. Lo que hay que conectar es el portal de tu empresa: debe comprobar quién ha iniciado sesión, localizar su cuenta de Feending y solicitar el enlace para esa persona. Si ya tenéis una intranet con acceso corporativo, podéis aprovecharla.

El mismo esquema puede utilizarse con un portal conectado a Active Directory u otro proveedor. Disponer de un directorio por sí solo no completa la conexión.

Acceder directamente desde la pantalla de Feending

Un botón «Acceder con mi empresa» que redirija al proveedor corporativo requiere una integración directa de identidad. La conexión corporativa directa mediante OIDC o SAML no está disponible como función estándar. Este escenario necesita desarrollo adicional.

Además de permitir el acceso, la conexión puede encargarse de crear las cuentas y mantener sus datos al día.

Por ejemplo, una incorporación registrada en RR. HH. puede necesitar una cuenta en Feending; un cambio de departamento puede afectar al perfil; una salida de la organización puede exigir retirar el acceso. Hay que implementar cada una de esas acciones.

Reconocer a la misma persona en los dos sistemas

La integración conserva la relación entre el identificador de vuestro sistema y el USER-{GUID} de Feending. La sección Cómo se enlazan los usuarios de ambos sistemas explica el alta, las cuentas existentes y las actualizaciones en ambos sentidos.

Qué ocurre al retirar el acceso corporativo

Cuando la conexión recibe una baja del directorio, solicita la desactivación en Feending. Esa operación impide nuevos accesos y revoca las sesiones existentes, conservando el historial. Reactivar la cuenta permite un nuevo acceso si cumple las demás condiciones; no recupera las sesiones anteriores.

La integración guarda qué cuenta de vuestro sistema corresponde a cada usuario de Feending. Los dos identificadores se conservan: no tienen que ser iguales.

Cuando la integración crea la cuenta

El sistema de personal envía su identificador, EMP-123, junto con los datos de la persona. Feending crea la cuenta, devuelve su identificador USER-{GUID} y guarda la referencia del sistema de origen. Esa referencia incluye el nombre del sistema, por ejemplo rrhh, para distinguirla de los identificadores de otras herramientas.

Cuando la persona ya tiene cuenta

Las cuentas también pueden relacionarse por email o DNI/NIF/NIE, cuando ese dato esté disponible en ambos sistemas. La integración compara el dato acordado, comprueba que identifica de forma inequívoca a la misma persona y guarda el enlace entre sus identificadores. Si hay duplicados, datos contradictorios o una dirección compartida, la coincidencia se revisa antes de enlazar.

Por ejemplo, el empleado EMP-123 se localiza en Feending por su correo o por su DNI/NIF/NIE. Cuando hay una única coincidencia, Feending guarda en su base de datos la relación entre EMP-123 y su USER-{GUID}, dentro de vuestra comunidad y para ese sistema. No se crea otra cuenta.

En las actualizaciones siguientes

Cuando cambia EMP-123, la conexión busca la cuenta de Feending que tiene asociada y actualiza esa cuenta. Si el cambio sale de Feending, utiliza la misma relación en sentido inverso para localizar al empleado en vuestro sistema.

Si cambia el correo o la persona causa baja

El email y el documento se utilizan para el emparejamiento inicial. Después, la relación se resuelve por los identificadores guardados, aunque cambien esos datos. Desactivar el acceso conserva el enlace. Si un identificador de empleado se reasigna a otra persona, la correspondencia debe revisarse antes de continuar.

Una web o aplicación puede utilizar información de Feending y ofrecer acceso a su comunidad desde el entorno que el cliente ya utiliza.

Mostrar actividades y publicaciones

El servidor de la web consulta los eventos o publicaciones disponibles en la API y presenta esa información con el diseño del cliente. Tu equipo decide cada cuánto actualizar esa información. Los datos que recibe dependen de la consulta utilizada y de qué contenido puede compartirse.

Registrar usuarios desde una aplicación

Tu aplicación puede crear una cuenta y guardar su identificador para futuras actualizaciones. Si la persona ya existe, la conexión debe comprobar que es la misma antes de vincularla. La creación de una cuenta y el envío de una invitación son acciones distintas.

Continuar en Feending desde una intranet

La intranet puede incorporar un acceso que solicita el enlace temporal para la persona autenticada y la redirige a Feending. La credencial de integración se guarda en el servidor; no se incorpora al código público de la web.

Inscribir a una persona en una actividad

Tu aplicación puede solicitar una inscripción indicando la persona, la actividad y, cuando corresponda, el tipo de entrada. Feending comprueba aforo, invitaciones y condiciones de acceso. Si requiere pago, devuelve el enlace para completarlo; la inscripción solo se confirma cuando se cumplen sus condiciones.

Qué necesita desarrollar el cliente

Tu equipo desarrolla las pantallas de vuestra web, conecta su servidor con la API y guarda la relación entre las cuentas de ambos sistemas. La referencia técnica incluye las peticiones y respuestas para cada operación disponible.

Las necesidades cambian según la herramienta que quieras conectar. Estos ejemplos explican qué información puede interesarte compartir y qué parte de la conexión hay que desarrollar.

La API cubre las operaciones descritas; la conexión también debe utilizar las funciones de la herramienta del cliente. Por ejemplo, sincronizar una agenda requiere relacionar los eventos y trasladar sus cambios de fecha o cancelaciones en ambos sentidos.

En una integración bidireccional, los cambios pueden viajar del sistema del cliente a Feending y de Feending al sistema del cliente. Para cada dato hay que definir dónde se puede editar y cómo se traslada el cambio.

Del sistema del cliente hacia Feending

1. Se detecta el cambio. El sistema externo envía un aviso a la dirección de recepción del conector, o un servicio de integración consulta periódicamente los cambios.
2. Se identifica el registro. La conexión comprueba el origen, encuentra la cuenta equivalente y adapta los datos al formato de destino.
3. Se aplica la operación. El servidor envía la actualización a la API, comprueba su respuesta y conserva la versión del registro.

De Feending hacia el sistema del cliente

Cuando se produce un cambio al que tu aplicación está suscrita, Feending envía un aviso a la dirección que se haya configurado. Tu aplicación recibe el aviso, localiza el registro y lo actualiza. También puede consultar la API periódicamente para recoger la información disponible.

Ejemplo: directorio y aplicación de comunidad

RR. HH. mantiene los datos del empleado y utiliza la API para actualizar su perfil y sus grupos en Feending. En el otro sentido, Feending envía un webhook cuando la persona se inscribe en una actividad. La aplicación del cliente recibe el aviso y actualiza su información de participación.

Dónde se envían los cambios

Para las operaciones habituales, el servidor del cliente envía la petición a la API de Feending: actualizar un usuario, cambiar sus grupos o modificar una actividad. Si la herramienta necesita otro formato o un proceso específico, un conector adapta sus mensajes a estas operaciones.

Puedes recibir las traducciones guardadas junto al contenido habitual de un webhook de plataforma. La opción se configura por conexión: activarla en una no modifica las demás.

Cómo se configura

En Configuración → Integraciones → Webhooks, activa «Incluir traducciones disponibles» en la suscripción correspondiente y guarda el cambio. Si no tienes acceso a esta pantalla, solicita la configuración al equipo de Feending. Las suscripciones existentes mantienen la opción desactivada hasta que se active expresamente.

Qué recibe tu web

El contenido conserva sus campos habituales y añade un bloque de traducciones organizado por idioma. Por ejemplo, un evento puede incluir el título original y su versión inglesa. Tu equipo de desarrollo debe adaptar el receptor para leer ese bloque y guardar cada idioma en WordPress u otro sistema de destino.

Qué debes tener en cuenta

• Solo se envían traducciones ya guardadas; el envío no genera textos nuevos ni garantiza todos los idiomas.
• La opción sirve para entidades y campos traducibles del objeto principal; no añade las traducciones de actividades o elementos hijos.
• Cambiar una traducción después del aviso no provoca otro envío automático.
• Las reglas de acceso y publicación del contenido siguen aplicándose.

Esta opción corresponde a los webhooks de plataforma con contenido completo. Los avisos por referencias de la API de integración conservan su formato.

Quién decide el valor de cada dato

Conviene decidir dónde se mantiene cada dato. Por ejemplo, el departamento puede actualizarse en RR. HH. y las inscripciones en Feending. Si un dato se puede editar en los dos sistemas, hay que decidir qué cambio se conserva cuando las ediciones coinciden.

Cuándo se refleja un cambio

Con los avisos, tu aplicación puede empezar a actualizar la información cuando recibe el cambio. Si consulta la API cada cierto tiempo, lo recogerá en la siguiente consulta. El tiempo total depende también de cuánto tarde cada sistema en procesarlo.

Evitar duplicados y cambios que vuelven al origen

La conexión conserva identificadores para reconocer entregas repetidas y actualizaciones ya aplicadas. También distingue los cambios recibidos de los generados localmente para evitar que dos sistemas se reenvíen la misma modificación indefinidamente.

Qué ocurre si un sistema no responde

Los webhooks firmados reintentan los fallos temporales. Tu equipo puede consultar si una entrega llegó, por qué falló y cuándo se volverá a intentar. Si necesita recuperar un periodo de cambios, utiliza el registro con cursor desde el último punto guardado.

Comprobar que la información vuelve a coincidir

La conexión guarda hasta qué cambio ha procesado y continúa desde ese punto. Las eliminaciones se notifican expresamente, para que no tenga que deducirlas de una ausencia. Si se supera el periodo de conservación del registro, vuelve a cargar los datos y compara ambos sistemas.

La conexión guarda un punto de lectura para recuperar los cambios pendientes sin volver a descargar todos los datos.

Qué es un cursor

Es una referencia que entrega Feending y que la aplicación del cliente guarda, como un marcador de lectura. Cuando vuelve a consultar, devuelve esa referencia para continuar desde el punto anterior.

Dos usos diferentes

Recorrer un listado. Si hay muchos usuarios, la aplicación los recibe por bloques. Cada bloque indica cómo pedir el siguiente, hasta completar el listado.

Mantener la información al día. Después de la primera carga, otro cursor permite consultar las altas, modificaciones y eliminaciones posteriores al último punto procesado.

Ejemplo: una conexión interrumpida

1. La aplicación sincroniza los usuarios y guarda el punto alcanzado.
2. Durante dos horas no puede conectarse. Mientras tanto, una persona cambia de departamento y otra causa baja.
3. Al reconectarse, pide los cambios desde el punto guardado, aplica ambos y conserva el nuevo punto de lectura.

Cómo se complementa con los webhooks

El webhook avisa de que algo ha ocurrido y permite reaccionar pronto. El registro de cambios permite recuperar lo pendiente aunque un aviso no haya llegado. La conexión utiliza ambos mecanismos para mantener los datos coordinados.

Qué ocurre tras una interrupción prolongada

El registro conserva los cambios durante un periodo limitado. Si el punto guardado es demasiado antiguo, la conexión vuelve a cargar los datos y comprueba las diferencias. La guía técnica detalla cómo realizar esta recuperación sin perder cambios ni repetir acciones.

Responsabilidad de cada parte

El equipo de desarrollo conecta las aplicaciones, relaciona sus usuarios y comprueba que los datos se actualicen correctamente. Tu organización decide quién tiene acceso y qué permisos necesita cada persona.

Seguridad del acceso corporativo

El servidor que solicita un enlace de acceso debe haber validado la identidad y la autorización de la persona. Los enlaces temporales y las claves son credenciales: no deben publicarse ni incluirse en registros compartidos.

Privacidad al publicar contenido

Recibir un aviso no autoriza a publicar sus datos en abierto. Permitir compartir un evento tampoco lo convierte en público: un evento exclusivo puede permitir compartir invitaciones. La conexión debe respetar acceso, audiencia y publicación, incluidos los elementos anidados, y retirar las copias que dejen de ser publicables. La guía técnica detalla los campos, los formatos y las pruebas de privacidad.

Documentación para el equipo de desarrollo

La guía para desarrolladores explica cómo autenticarse, qué peticiones enviar y cómo interpretar las respuestas. Incluye ejemplos completos, errores habituales y el código para comprobar la firma de los avisos.

Abrir la referencia técnica con ejemplos completos