Guía completa: Usar el Web API
Esta guía es un paso a paso para conectar un sistema externo (tu página web, una app propia, un middleware, otro software) al Web API de AdmCloud: cómo autorizar el uso del API creando una Integración, cómo autenticarse con Autenticación básica o con token, cómo hacer la primera llamada desde Swagger u otra herramienta, ejemplos de código listos para copiar, cómo leer la respuesta y dónde está la documentación completa de cada objeto.
¿Qué es el Web API y para qué sirve?
El Web API de AdmCloud es un API REST que expone, sobre HTTPS y en formato JSON, casi todo lo que puedes hacer desde la pantalla web: consultar y crear clientes, proveedores, artículos, cuentas contables, facturas, cotizaciones, pedidos, órdenes de compra, recepciones, depósitos, asientos contables, nómina y mucho más. Así, un sistema externo puede leer y registrar información en tu empresa sin que una persona tenga que entrar a la aplicación.
La dirección base del API en producción es https://api.admcloud.net/api/, y cada objeto
tiene su propia ruta. Por ejemplo, listar clientes es:
GET https://api.admcloud.net/api/Customers?skip=0&company=MiEmpresaDB&role=Administradores&appid=00000000-0000-0000-0000-000000000000
Todas las operaciones devuelven la misma envoltura de respuesta: un objeto JSON
con success (si la operación funcionó), message (el mensaje de error
cuando falla) y data (el resultado: un listado, un documento, un identificador...).
Esto se explica en detalle más abajo, en Cómo leer la respuesta.
Antes de empezar: lo que necesitas a mano
- Un plan que incluya el API: Basic o superior (no está disponible en Billing ni Start).
- El permiso de Personalización en tu grupo de usuarios, para poder crear la Integración.
- Un usuario y contraseña reales de AdmCloud: el API no tiene "llaves" independientes; siempre se autentica como un usuario de la empresa.
- El nombre de la base de datos de tu empresa (el parámetro
company). Lo ves en la pantalla de Integraciones con Web Services, en el campo Nombre de Base de Datos. - El nombre del grupo de usuarios con el que se ejecutarán las llamadas (el parámetro
role; por ejemplo Administradores). - El ID de la Integración (el parámetro
appid), que obtienes en el paso 1.
Paso 1: crear la Integración que autoriza el uso del API
Antes de la primera llamada hay que autorizar en el sistema al programa que va a consumir el API. Eso se hace creando una Integración: AdmCloud le asigna un identificador único (el appid) que viaja en cada llamada, de modo que cada sistema conectado quede identificado y puedas desactivarlo de forma independiente cuando quieras.
- Entra a Integraciones con Web Services (menú de Personalización / Administración del Sistema) y pulsa Nueva Integración.
- Escribe un Nombre descriptivo que identifique al sistema que la va a usar (por ejemplo, "Página web de pedidos" o "Integración con el punto de venta de la sucursal"). El nombre es obligatorio y no puede repetirse.
- Decide si la integración debe Ejecutar como Administrador (ver la advertencia más abajo) y agrega en Notas para qué se usa y quién la solicitó.
- Guarda. AdmCloud genera el ID de Integración (el appid), que ya no se puede cambiar.
- Entra al detalle de la integración recién creada. Ahí encuentras el appid, el nombre de la base de datos y una lista de URL de ejemplo ya armadas para los objetos más usados (Clientes, Proveedores, Artículos, Cuentas, Facturas, Órdenes de Compra, Depósitos, Asientos Contables, etc.). Es la forma más rápida de probar: copias una URL y la abres en el navegador.
| Campo de la Integración | Para qué sirve |
|---|---|
| Nombre | Identifica la integración. Obligatorio y único. |
| ID de Integración (appid) | El identificador que enviarás en cada llamada. Lo genera AdmCloud al guardar y no es editable. |
| Deshabilitada | Interruptor de emergencia: al activarlo, cualquier llamada que use ese appid deja de funcionar de inmediato, sin borrar la integración ni perder su historial. |
| Ejecutar como Administrador | Si está activo (valor por defecto), las llamadas con ese appid se ejecutan con acceso total, sin validar los permisos del usuario autenticado. Si lo desactivas, cada llamada respeta los permisos reales del usuario y su grupo, igual que en la pantalla web. |
| Notas | Texto libre para documentar el propósito de la integración. Solo lo ven los usuarios internos. |
El appid no sustituye al usuario y la contraseña. Es un dato adicional que viaja junto con las credenciales, no en lugar de ellas. Y ten cuidado con Ejecutar como Administrador: mientras esté activo, la integración pasa por encima de los permisos del usuario. Desactívalo cuando quieras que la integración pueda hacer exactamente lo mismo que ese usuario haría dentro de la aplicación.
Crea una integración por sistema, no una sola para todo. Así puedes deshabilitar o auditar una conexión sin afectar a las demás. Los campos y validaciones se explican con más detalle en la página Integraciones con Web Services (API).
Paso 2: autenticación básica (la forma más simple)
La Autenticación básica (Basic Authentication, el estándar de HTTP) es la
manera más directa de llamar al API: en cada llamada envías el correo y la contraseña del usuario en
el encabezado Authorization, y los datos de contexto (empresa, grupo e integración) como
parámetros de la dirección.
- Encabezado:
Authorization: Basic <correo:contraseña en Base64>. Casi todas las herramientas y librerías lo arman por ti: solo escribes usuario y contraseña. - Parámetro
company: el nombre de la base de datos de la empresa. Es lo que le dice al API en qué empresa trabajar. - Parámetro
role: el nombre del grupo de usuarios con el que se ejecuta la llamada (oroleidsi prefieres enviar su identificador). - Parámetro
appid: el ID de la Integración creada en el paso 1.
Una llamada completa se ve así:
GET https://api.admcloud.net/api/Customers?skip=0&company=MiEmpresaDB&role=Administradores&appid=8f3c1e42-...-9b21
Authorization: Basic dXN1YXJpb0BlbXByZXNhLmNvbTpNaUNsYXZl
Al recibir la llamada, AdmCloud valida en este orden:
- Que el correo y la contraseña sean correctos y la cuenta no esté bloqueada.
- Que ese usuario exista en la empresa indicada en
company. - Que el grupo de usuarios indicado en
role(oroleid) esté realmente asignado a ese usuario. - Que la Integración del
appidexista y no esté marcada como Deshabilitada. - Que el usuario tenga el privilegio necesario para la operación... salvo que la integración esté marcada como Ejecutar como Administrador, en cuyo caso este paso se omite.
Envía siempre role (o roleid). Si no lo envías, la
llamada no queda asociada a ningún grupo de usuarios y fallará con "Unauthorized" en cuanto se
validen privilegios (es decir, en cualquier integración que no esté como Ejecutar como
Administrador).
Si la autenticación falla, el API responde 401. Cuando el motivo es concreto
(contraseña incorrecta, cuenta bloqueada, empresa que no corresponde), el cuerpo de la respuesta
trae el mensaje real en message para que puedas mostrarlo en tu sistema.
Paso 3: autenticación con token
La alternativa es autenticarse una vez y luego usar un token. El token es una cadena
firmada que ya lleva dentro el contexto de la sesión (usuario, empresa, grupo, sucursal y ubicación),
así que en las llamadas siguientes no vuelves a enviar la contraseña: basta el parámetro
token. Es la opción recomendada cuando tu sistema hace muchas llamadas seguidas o cuando
no quieres que la contraseña viaje en cada solicitud.
-
(Opcional) Averigua las empresas del usuario. Llama con Autenticación básica y
sin el parámetro
companyaPOST /api/Login/GetCompanies. Devuelve las empresas del usuario, ordenadas por su último inicio de sesión, con su identificador y el nombre de su base de datos. -
Averigua el identificador del grupo de usuarios (
RoleID). Puedes obtenerlo llamando aPOST /api/Login/SelectCompany?CompanyID=..., que devuelve los grupos disponibles del usuario en esa empresa; o tomarlo del identificador que aparece en la dirección al abrir el grupo en Grupos de Usuarios dentro de la aplicación. -
Genera el token con Autenticación básica:
La respuesta trae el token en el campoPOST https://api.admcloud.net/api/Token?Company=MiEmpresaDB&RoleID=1c9a...&appid=8f3c1e42-...-9b21 Authorization: Basic dXN1YXJpb0BlbXByZXNhLmNvbTpNaUNsYXZldata. -
Usa el token en las demás llamadas, como parámetro
tokeny sin encabezado de autenticación:GET https://api.admcloud.net/api/Customers?skip=0&token=eyJhbGciOi...
| Autenticación básica | Token | |
|---|---|---|
| Qué envías en cada llamada | Usuario y contraseña + company, role y appid | Solo token |
| Cuándo conviene | Llamadas puntuales, pruebas, scripts sencillos | Sistemas que hacen muchas llamadas o mantienen una sesión |
| Permisos | Puede saltarse la validación de privilegios si la Integración está como Ejecutar como Administrador | Se validan siempre los privilegios reales del usuario y su grupo |
| Contexto (empresa, grupo, sucursal) | Se indica por parámetros en cada llamada | Viene dentro del token, fijado al generarlo |
Cuando llamas con token, el appid no viaja, así que
"Ejecutar como Administrador" no aplica: la llamada respeta siempre los permisos
del grupo de usuarios con el que se generó el token. Si una operación te funciona con
Autenticación básica y falla con token diciendo "Unauthorized", casi siempre es porque a ese
grupo le falta el privilegio.
El token tiene vencimiento. Tu sistema debe estar preparado para volver a generarlo (repitiendo el paso 3) cuando las llamadas empiecen a rechazarse por token inválido o expirado.
Paso 4: hacer la primera llamada con Swagger u otra herramienta
No necesitas escribir código para probar el API. La forma recomendada es Swagger, la documentación interactiva que además ejecuta las llamadas:
- Abre https://api.admcloud.net/ApiDocumentation/ (dentro de la aplicación, el mismo enlace está en el aviso informativo de la pantalla de Integraciones).
- Arriba encontrarás un selector de módulos. Como el API expone cerca de mil operaciones, la documentación está dividida en un documento por módulo (General, Accounts Payable, Accounts Receivable, Banking, General Ledger, Inventory, Payroll, Point of Sale, System Administration, etc.). Elige el módulo del objeto que buscas.
-
Despliega la operación que quieres probar (por ejemplo
GET /api/Customers) y pulsa Try it out. -
Llena los parámetros:
skipen 0,companycon el nombre de tu base de datos,rolecon el nombre de tu grupo de usuarios yappidcon el ID de la integración. Ejecuta. - La primera vez el navegador te pedirá usuario y contraseña (es el cuadro estándar de Autenticación básica que aparece al recibir el 401). Escribe tu correo y contraseña de AdmCloud; el navegador los reutilizará en las llamadas siguientes.
-
Revisa el cuerpo de la respuesta. Si
successestrue, ya estás consumiendo el API correctamente.
Otras herramientas igual de válidas:
- El navegador, sin más: copia una de las URL de ejemplo del detalle de tu Integración y ábrela. El navegador pedirá usuario y contraseña y te mostrará el JSON.
- El Explorador de API (apiexplorer.admcloud.net): una interfaz propia para explorar los objetos disponibles y sus parámetros.
- Postman, Insomnia o similares: crea la solicitud, en la pestaña de autorización elige Basic Auth y escribe tu correo y contraseña; agrega
company,roleyappidcomo parámetros de consulta. - curl, desde una terminal (ver el ejemplo más abajo).
El API solo atiende llamadas desde sus direcciones publicadas
(api.admcloud.net y los ambientes internos de pruebas). Si armas la URL con otro
dominio, la solicitud se rechaza con 401 aunque las credenciales sean correctas.
Paso 5: ejemplo sencillo de código
Los tres ejemplos hacen lo mismo: listar los primeros clientes con Autenticación básica. Cambia el correo, la contraseña, el nombre de la base de datos, el grupo y el appid por los tuyos.
curl
curl -u "usuario@empresa.com:MiClave" \
"https://api.admcloud.net/api/Customers?skip=0&company=MiEmpresaDB&role=Administradores&appid=8f3c1e42-...-9b21"
C#
using System;
using System.Net.Http;
using System.Net.Http.Headers;
using System.Text;
using System.Threading.Tasks;
class Program
{
static async Task Main()
{
const string EMAIL = "usuario@empresa.com";
const string PASSWORD = "MiClave";
const string COMPANY = "MiEmpresaDB";
const string ROLE = "Administradores";
const string APPID = "8f3c1e42-...-9b21";
using (var client = new HttpClient())
{
var credentials = Convert.ToBase64String(
Encoding.UTF8.GetBytes(EMAIL + ":" + PASSWORD));
client.DefaultRequestHeaders.Authorization =
new AuthenticationHeaderValue("Basic", credentials);
var url = "https://api.admcloud.net/api/Customers"
+ "?skip=0"
+ "&company=" + COMPANY
+ "&role=" + ROLE
+ "&appid=" + APPID;
var response = await client.GetAsync(url);
var json = await response.Content.ReadAsStringAsync();
Console.WriteLine(json);
}
}
}
JavaScript
const EMAIL = "usuario@empresa.com";
const PASSWORD = "MiClave";
const COMPANY = "MiEmpresaDB";
const ROLE = "Administradores";
const APPID = "8f3c1e42-...-9b21";
const url = "https://api.admcloud.net/api/Customers"
+ "?skip=0&company=" + COMPANY + "&role=" + ROLE + "&appid=" + APPID;
const response = await fetch(url, {
method: "GET",
headers: {
"Authorization": "Basic " + btoa(EMAIL + ":" + PASSWORD)
}
});
const result = await response.json();
if (result.success) {
console.log(result.data);
} else {
console.error(result.message);
}
Crear un registro es igual de sencillo: se usa POST a la misma ruta, con el objeto en
el cuerpo de la solicitud en JSON. La respuesta trae en data el identificador del
registro creado:
curl -u "usuario@empresa.com:MiClave" \
-H "Content-Type: application/json" \
-d '{ "Name": "Cliente de prueba", "Customer": true }' \
"https://api.admcloud.net/api/Customers?company=MiEmpresaDB&role=Administradores&appid=8f3c1e42-...-9b21"
Nunca pongas el usuario y la contraseña en código que corra en el navegador del cliente (una página pública, una app de escritorio distribuida). En esos casos, tu servidor debe ser el que llame al API y guardar las credenciales fuera del alcance del usuario final. El ejemplo de JavaScript de arriba es para código de servidor o pruebas locales.
En el repositorio de ejemplos en C# hay proyectos completos y funcionales para varios objetos, y en el video explicativo se recorre el proceso completo en pantalla.
Cómo leer la respuesta y paginar
Todas las operaciones responden con la misma estructura:
{
"success": true,
"message": null,
"data": [ ... ]
}
| Campo | Qué contiene |
|---|---|
success | true si la operación se ejecutó correctamente; false si falló. |
message | El mensaje de error cuando success es false. Vacío o nulo cuando todo salió bien. |
data | El resultado: un listado, un documento completo, un identificador (GUID) del registro creado, etc., según la operación. |
Un error de negocio no llega como error HTTP. Si el documento no cumple una
validación, la respuesta sigue siendo 200 pero con success: false y
el detalle en message. Tu sistema debe revisar siempre success, no solo
el código HTTP.
Los listados están paginados: devuelven como máximo 50 registros por
llamada. Para recorrer todo, ve aumentando el parámetro skip (0, 50, 100, ...) hasta que
una llamada devuelva un listado vacío.
Dónde está la documentación del API
Todos estos recursos están enlazados en el aviso informativo de la pantalla de Integraciones con Web Services y también en el detalle de cada integración:
| Recurso | Qué encuentras |
|---|---|
| Documentación Swagger | La referencia técnica completa y ejecutable: todas las operaciones agrupadas por módulo, cada parámetro con su tipo y obligatoriedad, la estructura del cuerpo de cada documento y el botón para probar la llamada en vivo. Es la fuente oficial. |
| Explorador de API | Una herramienta para navegar los objetos disponibles y armar llamadas de forma guiada. |
| Video explicativo | El recorrido completo en pantalla: crear la integración, autenticarse y hacer la primera llamada. |
| Código de ejemplo en C# | Proyectos de ejemplo listos para compilar y ejecutar. |
| Detalle de tu Integración | URL de ejemplo ya armadas con tu appid y tu base de datos, para los objetos más usados. El atajo más rápido para la primera prueba. |
Desde dentro de la aplicación también puedes abrir la documentación en la dirección
/ApiDocumentation, que te lleva a la misma página de Swagger.
Buenas prácticas de seguridad
- Usa un usuario dedicado para el API, no la cuenta personal de una persona. Al crear el usuario puedes marcarlo como Solo para API: así no puede iniciar sesión en la aplicación web ni le caducará la contraseña, lo que evita que una integración deje de funcionar de un día para otro.
- Dale a ese usuario un grupo con los permisos mínimos necesarios y desactiva Ejecutar como Administrador en la integración, para que el API no pueda hacer más de lo que ese grupo permite.
- Una integración por sistema conectado, con notas que expliquen su propósito.
- Deshabilita la integración en cuanto un sistema deje de usarse o notes actividad extraña; es inmediato y reversible, y conserva el historial.
- Guarda las credenciales del lado del servidor, nunca en código que se descargue al navegador del usuario final.
- Llama siempre por HTTPS a las direcciones publicadas del API.
Consejos y errores comunes
Recibo 401 sin mensaje. Falta un método de autenticación válido: no enviaste el
encabezado Authorization, ni token, ni appid; o la
dirección que estás llamando no es una de las publicadas del API. Revisa también que el
encabezado use el esquema Basic.
La respuesta dice que la integración no existe. El appid está mal copiado, pertenece a otra empresa, o la integración está marcada como Deshabilitada. Confírmalo en el detalle de la integración.
La respuesta dice "Unauthorized". Las credenciales están bien, pero al grupo de
usuarios le falta el privilegio de la operación (por ejemplo, permiso de agregar sobre Clientes),
o no enviaste el parámetro role y la llamada quedó sin grupo asociado.
El usuario no aparece en la empresa. El nombre en company debe ser
el nombre de la base de datos (el que se muestra en la pantalla de
Integraciones), no el nombre comercial de la empresa. Y el usuario debe existir en esa empresa
con el mismo correo.
Prueba siempre primero un GET sencillo (por ejemplo Clientes o Artículos) antes de intentar crear documentos. Si el GET funciona, ya tienes resueltas la autenticación, la empresa, el grupo y la integración, y cualquier error posterior será de los datos que envías.