WEB API - Documento Técnico
Propiedades del Documento
Autor HRDEV Team
Fecha 10/JAN/2020
Descripción Documento de detalle de APIs
Documentos
N/A
Relacionados
Distribución Público
Versión Fecha Autor Comentarios
01 10/JAN/2020 HRDEV Team Versión inicial
02 19/SEP/2022 Jonathan Izquierdo Actualización de URLs e Hiperlinks
03 20/SEP/2022 Pablo Macchi Ajustes finales, Ajustes a texto, formato
documento, look & feel
Pág. 2
WEB API
Introducción
VISMA Latinoamérica para su línea de productos de administración de personal: Visma
People & Payroll, ofrece un conjunto de integraciones que llamamos “WEB API” que se
disponibiliza sin costo para todos nuestros clientes y que el objetivo principal es facilitar
el acceso en tiempo real, de forma sincrónica, a su información en nuestra nube.
Su propósito principal es brindar una interfaz amigable y segura para ser utilizada por
cualquier programador experimentado y con la cual sea fácil integrar nuestra solución
cloud a sus sistemas legados existentes, utilizando una arquitectura muy probada y
ampliamente difundida hoy en día como ser API REST.
Para ello la WEB API ofrece un conjunto de servicios típicos, por ejemplo: Crear un
nuevo empleado, Obtener datos de un empleado, Obtener direcciones, Obtener
familiares, etc.
Documentación Detallada
Lo primero a saber es que la WEB API como tal consta de 2 URLs:
● https://webapi.vismalatam.com/help/index
● https://webapiadmin.vismalatam.com/help/index
La primera URL es donde se alojan la gran mayoría de servicios disponibles. La segunda
URL es la que corresponde a la parte “Administrativa”, donde la mayoría de los servicios
no están al alcance de usuarios comunes y sí a un usuario Administrador.
Pág. 3
Dentro de los servicios que sí tienen todos acceso se encuentra el que permite hacer el
Login (necesario para establecer una sesión y a partir de allí poder consumir los demás
servicios a disposición), así como el servicio para saber a qué Bases de Datos se tiene
acceso con las credenciales utilizadas al realizar el Login.
Documentación Técnica
Toda la documentación técnica que un desarrollador necesita para poder consumir los
servicios está publicada en las URLs listadas arriba. Esta documentación es auto-
generada cada vez que se despliega una nueva versión de la WEB API, por lo que se
garantiza que la información allí provista siempre estará al día y consistente. Esto es
gracias al Sistema Swagger, una herramienta que permite documentar y probar las APIs.
Es así como no sólo se puede explorar la lista de servicios y su correspondiente
información (cabecera de los mensajes, parámetros, estructura de las respuestas, etc.)
sino que también se pueden probar los servicios a través del navegador mismo, sin
necesidad de escribir código de programación.
Pág. 4
Login
El primer paso a entender es que la WEB API (así como casi cualquier otra aplicación
de negocios) requiere que el usuario que desee usarla realice un Login, previo al
posterior consumo de los servicios. Esto se debe a que al proveer las credenciales
(usuario y clave) la WEB API determina los roles y permisos del usuario y así permitirá
o denegará las peticiones a ciertos servicios, en función de si el usuario tiene
suficientes permisos.
Por lo tanto, el primer servicio a consumir es el del Login. No obstante, una vez hecho
esto satisfactoriamente, la WEB API devuelve un Token (in Base64 format), el cual
sirve de “vale” para el acceso al resto de los demás servicios.
Autenticación con Token
Este tipo de autenticación es un esquema de autenticación HTTP que cuenta con
tokens de seguridad llamados “bearer” (portador), ya que para
identificarse/autenticarse frente al sistema hay que ser portador de un token. El
token es una cadena de caracteres encriptada, que una vez recibida tras realizar un
Login exitoso, el cliente debe enviarla siempre en todas las peticiones que haga a la
WEB API, en función de poder validar y conceder su permiso para dichas acciones.
Autorización
Una vez autenticado, ya se tiene un Token de acceso y por lo tal se pueden consumir
el resto de los servicios, pero esto no significa necesariamente que se tenga permisos
para todos. Cada servicio tiene sus propias restricciones de seguridad, establecida
según “roles”, de modo tal que si el usuario con el que se realizó el Login no tiene los
roles que un servicio requiere, la petición fallará, acusando una denegación en la
respuesta justamente debido a esto.
Pág. 5
Relación entre Usuario, Token y Tenants
Para entender mejor la relación entre Usuario, Token y Tenants creemos conveniente
reforzar los siguientes conceptos:
Las credenciales (usuario & clave) son las que se utilizarán únicamente para generar
un token de acceso.
Este token será un parámetro requerido en todos los demás servicios de la WEB API,
ya que mediante el token la WEB API realiza la autenticación y autorización a los
distintos servicios.
El tenant es la instancia de la aplicación asignada al cliente a la cual se conectará cada
vez que se consuma un servicio, indicando así con qué fuente de datos trabajar.
Pág. 6
Autenticación
Ilustrado en el siguiente diagrama de flujo, se describe la secuencia de pasos a seguir
para autenticarse frente al sistema:
1. Primer paso - Servicio "/authentication/login"
Realizar una petición al servicio "/authentication/login" para loguearse, enviando las
credenciales (usuario y password). Si la respuesta es exitosa, se obtiene el Token de
acceso.
Importante: no es necesario consumir este servicio previamente cada vez que se vaya
a consumir un servicio de la WEB API, basta con hacerlo sólo una vez. Eventualmente,
sí se deberá volver a realizar nuevamente el Login, y así obtener un nuevo Token,
debido a alguna de las siguientes dos circunstancias:
● Se consumió el servicio "/authentication/logout"
● O bien se expiró el tiempo de validez del Token.
Pág. 7
Como toda sesión de usuario, tiene un período que caduca tras determinado
tiempo, y cuando esto sucede, el Token también caduca y deja de ser válido.
Nota: el parámetro “grant_type” es un valor fijo: “password”.
La respuesta será similar a la siguiente
Allí principalmente interesan los valores de:
• “expires_in”, que representa el tiempo (expresado en segundos) que el
Token será válido hasta ser considerado como caducado. En este ejemplo,
el valor 43.199 (segs) significa que el Token se podrá utilizar durante 12
horas, y habiendo transcurrido ese lapso de tiempo, el mismo quedará
inutilizado.
Pág. 8
• “access_token”, que es lo que se deberá enviar como parámetro al
consumir otros endpoints.
2. Segundo paso - Servicio "/account/tenants"
Realizar una petición al servicio "/accounts/tenants" para obtener información de a qué
bases de datos (“tenants”) se tiene concedido el permiso para poder trabajar con
ellas. A este servicio - y cualquier otro - se debe presentar el Token.
Aclaración: el Identificador del Tenant o Base de Datos nunca cambiará, por lo que en
realidad basta con consultar este servicio una única vez para obtener este dato.
Para mayor información sobre este flujo, revisar la documentación detallada.
Utilizar en la pestaña “Authorization” el token obtenido, seleccionando el type
“Bearer”:
La respuesta será similar a la siguiente:
Pág. 9
• “Id”, que es el identificador de la Base de Datos.
• “TenantName”, que es el nombre de la Base de Datos.
• “WebApiEnabled”, que indica si la Base de Datos está habilitada para
consumir vía Web API.
3. Tercer paso - Otros Servicios
Una vez que ya se cuenta con un Token y un Tenant, se puede comenzar a
consumir todo el resto de los servicios disponibles, en donde siempre – sin
excepción – se deberá informar el ID del Tenant en el parámetro “X-RAET-Tenant-Id”
y el Token en el parámetro “Authorization”.
Ejemplo, Servicio employee:
Pág. 10
Códigos de Respuesta
● 2xx Success
● 4xx Client Error
● 5xx Client Error
Cabe mencionar que la lista completa de código de estado/respuesta HTTP es más
extensa, pero aquí sólo nos acotamos a los que la WEB API considera. Para mayor
información, ver Lista completa de códigos de estado HTTP
2xx Success
Los códigos que comienzan con un 2 reflejan que el servidor ha podido resolver
exitosamente la petición del cliente.
Código Nombre Significado
200 OK La petición ha sido resuelta exitosamente en el servidor.
No La petición ha sido resuelta exitosamente en el servidor, y no hay
204
Content contenido a enviar en la misma hacia el cliente.
4xx Client Error
Los códigos que comienzan con 4 reflejan que el servidor identificó que hay algo
“incorrecto” en la solicitud del cliente, y por eso la rechaza/niega. Esto puede ser o un
error concreto en cómo se formuló la petición (400) o bien aún ésta estando bien, se
intenta acceder a un servicio inexistente (404), a un servicio al cual no tenemos acceso
(403), o bien directamente la solicitud no está autenticada (401).
Pág. 11
Código Nombre Significado
La petición presenta problemas o bien en su conformación, y no es
exactamente lo que está esperando el servidor. Esto se puede deber
400 Bad Request
a algún parámetro faltante, o bien valores incorrectos (por ejemplo,
una fecha no válida).
La petición ha sido denegada porque no se han presentado
401 Unauthorized credenciales o token de acceso válidos (el usuario no está
autenticado).
La petición ha sido denegada debido a que el usuario con el que se
403 Forbidden está autenticado no posee permisos para acceder al servicio en
cuestión.
La petición no ha encontrado ningún servicio/recurso en la dirección
404 Not Found
URL provista.
Quota
exceeded Se ha superado el limite de servicios definido en la cuota de
429
servicios
Pág. 12
5xx Server Error
Los códigos que comienzan con 5 reflejan que el servidor ha encontrado un problema
y ocurrió un error. En este caso, el cliente está haciendo lo debido y es el código del
servidor el que presenta fallas.
Código Nombre Significado
Internal Server La petición no ha sido resuelta exitosamente debido a un error de
500
Error procesamiento en el servidor.
IDs (Internos & Externos)
Un identificador (comúnmente referido sencillamente como “ID”) es una propiedad
unívoca para identificar a un recurso, por el cual siempre se podrá ubicar/encontrar al
mismo. Esto implica que el ID debe ser inmutable. En el contexto de una base de
datos, esto es típicamente la “PK” (Primary Key o Clave Primaria) de una tabla, y este
concepto es virtualmente el mismo aplicado al contexto de la WEB API.
IDs en la WEB API
● Hay 2 tipos de IDs: Internos y Externos:
o Los IDs internos son valores estrictamente relacionados con los IDs en el repositorio de datos,
los cuales el usuario puede o no conocer de antemano. Por esta razón, existe el segundo tipo de
ID.
o Los IDs externos son valores con los que el usuario está más familiarizado, por lo que en muchos
casos le será más fácil usar éstos en vez de los IDs internos. Para ilustrar esto con un ejemplo,
pensar en un libro. Probablemente no se conozca el ID interno del registro en una base de datos
donde se listen libros (eso sería la Primary Key), pero sí es más accesible el código ISBN (está
impreso en todos los libros del mundo), el cual no es un valor determinado arbitrariamente por la
base de datos sino un estándar mundial para identificar libros.
Pág. 13
Un escenario similar se puede aplicar a la WEB API de VISMA: al buscar por datos de un
empleado, el usuario puede consumir un servicio que requiere se indique su ID para
saber de qué empleado se devolverá la información. Ahora bien, la WEB API tiene a
disposición del usuario la posibilidad de utilizar el servicio enviando el ID interno del
empleado o bien su legajo (el ID externo, en este caso) para obtener exactamente la
misma respuesta.
● A continuación, se ve un ejemplo de cómo se ven las rutas URL en ambos casos:
o Usando el ID externo (legajo del empleado):
https://webapi.vismalatam.com/api/employees/10941307
o Usando el ID interno (id de la tabla de empleados en la base de datos)
https://webapi.vismalatam.com/api/employees/rh-22008
En resumen, los IDs internos son identificadores que la WEB API utiliza para poder
encontrar la información en la base de datos. Los ID externos son un medio más
“amigable” provisto especialmente para que los usuarios puedan consumir los
servicios con mayor facilidad. De todos modos, como se ha mencionado
anteriormente, el uso ambos dos es totalmente intercambiables y la respuesta no será
alterada; el resultado es el mismo.
Pág. 14
Política de uso aceptable de la WEB API
Para ofrecer la máxima disponibilidad y fiabilidad de los recursos compartidos de
nuestra plataforma cloud, todos los clientes que acceden a la WEB API están sujetos a
unos determinados límites y cuotas definidos por cada instancia de la aplicación.
Cuando se detecten consumos mayores a lo permitido del servicio se interrumpirá de
forma automática retornando un error de sobrepaso del límite de cuota permitida.
Si se supera la cuota de solicitud a la WEB API, ésta devolverá el código de error 429 y
un mensaje indicando que la instancia ha superado la cuota permitida.
Los límites de cuota son diarios, en caso de sobrepaso deberá esperar hasta el día
siguiente.
Límites de cuotas para la WEB API
Se define como límite de cuota de uso las siguientes restricciones:
● Hasta 18.000 consumos diarios (contando el consumo de cualquiera de los
servicios/endpoints)
● Hasta 200 consumos por segundo
Pág. 15
Códigos de Ejemplo
● Login
● Obtener Tenants del Usuario
● Obtener Empleados
Cabe mencionar que la lista completa de código de estado/respuesta HTTP es más
extensa, pero aquí sólo nos acotamos a los que la WEB API considera. Para mayor
información, ver Lista completa de códigos de estado HTTP
Importante: La conexión se debe establecer bajo el protocolo TLS V1.2 o versión superior, versiones
anteriores de TLS no son aceptadas dado vulnerabilidades que han sido detectadas y el servidor denegará la
petición.
Pág. 16
Login
Ejemplo de consumo al servicio "/authentication/login" para realizar la autenticación de
un usuario.
Código Javascript
xmlHttpRequest = new XMLHttpRequest();
xmlHttpRequest.onreadystatechange = function()
{
if (xmlHttpRequest.readyState == XMLHttpRequest.DONE)
{
if (xmlHttpRequest.status == 200)
{
/* Expected data structure:
{
"access_token": "string",
"token_type": "string",
"expires_in": "string"
}
*/
var response = JSON.parse( xmlHttpRequest.response );
var token = response.access_token;
}
else
{
// handle the error..
}
}
};
xmlHttpRequest.open('POST', 'https://webapi.vismalatam.com/Admin/authentication/login', true);
xmlHttpRequest.setRequestHeader('Content-type', 'application/x-www-form-urlencoded');
xmlHttpRequest.send('username=YOUR_USER&password=YOUR_PASS&grant_type=password'); /* replace
YOUR_USER & YOUR_PASS by the real values */
Pág. 17
Pág. 18
Código jQuery
$.ajax
({
url: 'https://webapi.vismalatam.com/Admin/authentication/login',
type: 'POST',
dataType: 'text',
data: 'username=YOUR_USER&password=YOUR_PASS&grant_type=password', /* replace YOUR_USER
& YOUR_PASS by the real values */
beforeSend: function (xhr, settings)
{
xhr.setRequestHeader( 'Content-Type', 'application/x-www-form-urlencoded' );
}
})
.done(function (data, textStatus, jqXHR)
{
/* Expected data structure:
{
"access_token": "string",
"token_type": "string",
"expires_in": "string"
}
*/
var response = JSON.parse( xmlHttpRequest.response );
var token = response.access_token;
})
.fail(function (jqXHR, textStatus, errorThrown)
{
// handle the error..
}
)
Pág. 19
Código PHP
$username = "YOUR_USER"; // replace by real value
$password = "YOUR_PASS"; // replace by real value
$data_array = array(
"username" => $username,
"password" => $password,
"grant_type" => "password"
);
$curl = curl_init();zz
curl_setopt($curl, CURLOPT_URL, "https://webapi.vismalatam.com/Admin/authentication/login");
curl_setopt($curl, CURLOPT_HTTPHEADER, array("Content-Type: application/x-www-form-urlencoded"));
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
curl_setopt($curl, CURLOPT_POST, true);
curl_setopt($curl, CURLOPT_POSTFIELDS, $data_array);
$response = curl_exec($curl);
curl_close($curl);
/* Expected data structure:
{
"access_token": "string",
"token_type": "string",
"expires_in": "string"
}
*/
$decoded_response = json_decode($response);
$token = $decoded_response.access_token;
Pág. 20
Código C#
public class AuthToken
{
public string Access_ get; set; }
public string Token_T get; set; }
public int Expires_In { get; set; }
}
using (var webClient = new WebClient() { Encoding = Encoding.UTF8 })
{
webClient.Headers[HttpRequestHeader.ContentType] = "application/x-www-form-urlencoded";
string data = $"username={YOUR_USER}&password={YOUR_PASS}&grant_type=password";
string responseData =
webClient.UploadString("https://webapi.vismalatam.com/Admin/authentication/login", data);
AuthToken authToken = JsonConvert.DeserializeObject[AuthToken](responseData);
string token = authToken.Access_Token;
}
Pág. 21
Obtener listado Tenants asociadas a un usuario
Ejemplo de consumo al servicio "/accounts/tenants" para obtener la lista de bases de
datos/tenants a los cuales el usuario provisto (mediante el Token) tiene acceso.
Código Javascript
var xmlHttpRequest = new XMLHttpRequest();
xmlHttpRequest.onreadystatechange = function()
{
if (xmlHttpRequest.readyState == XMLHttpRequest.DONE)
{
if (xmlHttpRequest.status == 200)
{
/* Expected data structure:
[{
"Id": "string",
"ClientName": "string",
"TenantName": "string",
"WebApiEnabled": true,
"EmployeeSecurityStrategy": "string",
"Version": "string"
}]
*/
}
else
{
// handle the error..
}
}
};
xmlHttpRequest.open('GET', 'https://webapi.vismalatam.com/Admin/account/tenants', true);
xmlHttpRequest.setRequestHeader( 'Authorization', 'Bearer ACCESS_TOKEN' ); /* replace ACCESS_TOKEN by the
real value */
xmlHttpRequest.setRequestHeader( 'X-Api-Version', '1.0-preview.1' );
xmlHttpRequest.send();
Pág. 22
Pág. 23
Código jQuery
$.ajax
({
url: 'https://webapi.vismalatam.com/Admin/account/tenants',
type: 'GET',
dataType: 'json',
beforeSend: function (xhr, settings)
{
xhr.setRequestHeader( 'Authorization', 'Bearer ACCESS_TOKEN' ); /* replace
ACCESS_TOKEN by the real value */
xhr.setRequestHeader( 'X-Api-Version', '1.0-preview.1' );
}
})
.done(function (data, textStatus, jqXHR)
{
/* Expected data structure:
[{
"Id": "string",
"ClientName": "string",
"TenantName": "string",
"WebApiEnabled": true,
"EmployeeSecurityStrategy": "string",
"Version": "string"
}]
*/
})
.fail(function (jqXHR, textStatus, errorThrown)
{
// handle the error..
})
Pág. 24
Código PHP
$curl = curl_init();
$token = "YOUR_TOKEN"; // replace by real value
curl_setopt($curl, CURLOPT_URL, "https://webapi.vismalatam.com/Admin/account/tenants");
curl_setopt($curl, CURLOPT_HTTPHEADER, array("Content-Type: application/json", "Authorization: Bearer
".$token, "X-Api-Version: 1.0-preview.1" ));
curl_setopt($curl, CURLOPT_CUSTOMREQUEST, "GET");
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($curl);
curl_close($curl);
/* Expected data structure:
[{
"Id": "string",
"ClientName": "string",
"TenantName": "string",
"WebApiEnabled": true,
"EmployeeSecurityStrategy": "string",
"Version": "string"
}]
*/
$decoded_response = json_decode($response);
Pág. 25
Código C#
using (var webClient = new WebClient() { Encoding = Encoding.UTF8 })
{
webClient.Headers.Add( "Authorization", "Bearer ACCESS_TOKEN" ); /* replace ACCESS_TOKEN by the
real value */
webClient.Headers.Add( "X-Api-Version", "1.0-preview.1" );
try
{
employeeData =
webClient.DownloadString("https://webapi.vismalatam.com/Admin/account/tenants");
}
catch (WebException ex)
{
HttpWebResponse httpResponse = ex.Response as HttpWebResponse;
// Handle the error (switch on httpResponse.StatusCode)
}
}
Pág. 26
Obtener listado de Empleados
Ejemplo de consumo al servicio "/employees" para obtener el listado (paginado) de
Empleados de una base de datos provista.
Código Javascript
var xmlHttpRequest = new XMLHttpRequest();
xmlHttpRequest.onreadystatechange = function()
{
if (xmlHttpRequest.readyState == XMLHttpRequest.DONE)
{
if (xmlHttpRequest.status == 200)
{
// handle de returned data..
}
else
{
// handle the error..
}
}
};
xmlHttpRequest.open('GET', 'https://webapi.vismalatam.com/WebApi/employees', true);
xmlHttpRequest.setRequestHeader( 'Authorization', 'Bearer ACCESS_TOKEN' ); /* replace ACCESS_TOKEN by the
real value */
xmlHttpRequest.setRequestHeader( 'X-Api-Version', '1.0-preview.1' );
xmlHttpRequest.setRequestHeader( 'X-RAET-Tenant-Id', TENANT_ID ); /* replace TENANT_ID by the real value */
xmlHttpRequest.send();
Pág. 27
Código jQuery
$.ajax
({
url: 'https://webapi.vismalatam.com/WebApi/employees',
type: 'GET',
dataType: 'json',
beforeSend: function (xhr, settings)
{
xhr.setRequestHeader( 'Authorization', 'Bearer ACCESS_TOKEN' ); /* replace
ACCESS_TOKEN by the real value */
xhr.setRequestHeader( 'X-Api-Version', '1.0-preview.1' );
xhr.setRequestHeader( 'X-RAET-Tenant-Id', TENANT_ID ); /* replace TENANT_ID by the real
value */
}
})
.done(function (data, textStatus, jqXHR)
{
// handle de returned data..
})
.fail(function (jqXHR, textStatus, errorThrown)
{
// handle the error..
})
})
Pág. 28
Código PHP
$curl = curl_init();
$token = "YOUR_TOKEN"; // replace by real value
$tenantId = "TENANT_ID"; // replace by real value
curl_setopt($curl, CURLOPT_URL, "https://webapi.vismalatam.com/WebApi/employees");
curl_setopt($curl, CURLOPT_HTTPHEADER, array("Content-Type: application/json", "Authorization: Bearer
".$token, "X-Api-Version: 1.0-preview.1", "X-RAET-Tenant-Id: ".$tenantId));
curl_setopt($curl, CURLOPT_CUSTOMREQUEST, "GET");
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($curl);
curl_close($curl);
$decoded_response = json_decode($response);
Pág. 29
Código C#
using (var webClient = new WebClient() { Encoding = Encoding.UTF8 })
{
webClient.Headers.Add( "Authorization", "Bearer ACCESS_TOKEN" ); /* replace ACCESS_TOKEN by the
real value */
webClient.Headers.Add( "X-Api-Version", "1.0-preview.1" );
webClient.Headers.Add( "X-RAET-Tenant-Id", TENANT_ID ); /* replace TENANT_ID by the real value */
try
{
employeeData =
webClient.DownloadString("https://webapi.vismalatam.com/WebApi/employees");
}
catch (WebException ex)
{
HttpWebResponse httpResponse = ex.Response as HttpWebResponse;
// Handle the error (switch on httpResponse.StatusCode)
}
}
Pág. 30
FAQ - Preguntas Frecuentes
¿La WEB API puede ser utilizada por un usuario final?
Las WEB API son integraciones pensadas para ser utilizadas por una audiencia técnica como ser
programadores/arquitectos que generalmente se encuentran en los departamentos de IT o en proveedores de
este tipo de servicio de desarrollo. Visma Latinoamérica provee el servicio a ser consumido a través de un
código que deberá ser construido por el equipo técnico de cada cliente a medida de resolver su propia
necesidad de integración con otros sistemas legados de su compañía.
¿Para acceder a la documentación se requiere de un usuario y contraseña?
Para acceder a la documentación, no se requiere de usuario/contraseña.
Para poder consumir los servicios, SI se requiere.
¿Tiene un costo adicional utilizar la WEB API?
Actualmente las condiciones comerciales de Visma Latinoamérica incluyen el costo del servicio de WEB API
junto a la suscripción de Visma People por lo cual no tiene un costo distinto.
¿Puedo utilizar la WEB API tanto como desee?
Para mantener nuestra calidad de servicio cloud tenemos definidos límites en la cuota de cantidad de
consumiciones de servicios totales diarios. Superada la cuota diaria la WEB API solo devuelve el error de límite
de cuota superada. Ver sección de “Política de uso aceptable de la WEB API” para mayor detalle. El equipo de
DevOps de Visma Latam monitorea proactivamente la utilización de las mismas para asegurar que el límite de
la cuota es razonable y suficiente para un uso cotidiano de todos nuestros clientes.
¿Cómo obtengo el usuario y contraseña para acceder a consumir los servicios de la WEB API?
El pedido de un usuario de WEB API se realiza mediante la creación de un ticket en la mesa de ayuda de Visma
Latam.
¿El Cliente necesita algo más para comenzar a utilizar los servicios?
Al ingresar a través de un navegador Web a las direcciones mencionadas previamente, se obtiene toda la
documentación técnica sobre cómo un desarrollador debe utilizarlas.
¿Existen APIs para acceder a toda la información en la aplicación?
Día a día nos esforzamos por seguir sumando más y mejores servicios REST, hoy contamos con los servicios
principales utilizados por más de 100 clientes. En algunos casos específicos, existen otras formas de
integración mediante la utilización de otro tipo de protocolos como ser intercambio de archivos a través de
servidores seguros (SFTP) que ya están tendiendo a dejar de utilizarse.
¿Si luego de leer toda la información, tengo dudas que puedo hacer?
Pág. 31
Si bien la documentación es muy detallada, entendemos que así y todo pueden existir dudas o consultas
técnicas (especialmente durante el primer uso). Desde nuestra Mesa de Ayuda, solicitándolo mediante la
creación de un ticket, ofrecemos un taller de asesoría técnica para programadores donde damos esta
inducción, con ejemplos y mejores prácticas a tener en cuenta. Es pre-requisito contar con experiencia del
equipo técnico del Cliente en cuanto a arquitecturas REST.
Pág. 32
