API & integrations (CRM, Make, n8n)

Can list and look up that resource. Any attempt to create, change or archive gets a 403 error with code PERMISO_DENEGADO and the missing permission.

Besides looking up, it can create, update and archive in that resource. It is the permission a two-way sync needs.

Permissions are per resource, and it already showed: when suppliers were added, the keys that existed — all of them for customers — did NOT gain access to them. It had to be ticked. The same will hold for any resource added later: an integration never sees more than what you granted.

The fields are the same as in the customer record: nombre and tipo (particular or empresa) are required; nif_cif, apellidos, razonSocial, email, telefono, telefonoSecundario, direccion (calle, numero, piso, codigoPostal, localidad, provincia, pais) and notas are optional. The tax id is stored in upper case and the email in lower case. In responses every key is always present, with null when there is no value, so the field mapping in your tool never breaks. Watch the name: nombre is the first name (or the business name for a company) and the last name goes separately in apellidos, plural.

If the body includes a key that doesn't exist (for example firstName instead of nombre, or the singular apellido instead of apellidos), the request isn't rejected, but that value isn't saved. So it doesn't go unnoticed, the response when creating or editing a customer includes avisos.camposIgnorados listing those keys; address keys include their path, such as direccion.ciudad. If you see it, check your integration's field mapping. Fields the API itself returns (id, codigo, createdAt…) never trigger it, so you can read a customer, change it and send it back in full.

Only nombre is required. Optional: codigo, cif, email, telefono, telefonoSecundario, web, direccion (a single line, not an object as in customers), ciudad, provincia, codigoPostal, pais, contactos, tipoProveedor (general, producto, servicio, logistica or otro), formaPago, plazoPago (in days; 0 means on delivery), cuentaCliente and notas. Each contact has nombre —required—, cargo, telefono, email and notas; contacts have no identifier of their own.

The list you send REPLACES the one that was there. An empty list deletes every contact; omitting the key (or sending null) leaves them untouched. That is what lets you read a supplier, change one field and send the whole thing back without surprises.

Unlike the customer code, the supplier code (PROV-004) is not unique: it can repeat even inside your own shop. That is why GET /proveedores/{id} only accepts the id. If your ERP only stores the code, use the list filter: GET /proveedores?codigo=PROV-004 returns everything that matches and you decide.

Each ticket includes numeroFicha, estado, prioridad, ubicacion, averiaDeclarada, diagnostico, the lifecycle dates (check-in, diagnosis and repair start and end, customer notice, pickup and ultimoCambioEstado, when it entered its current status), a client summary (id, codigo, codigoVisible, nombre, apellidos, razonSocial), the device (id, codigo, tipo, marca, modelo, numeroSerie, imei, color), the estimate (numero, total, estado, fechaEnvio and fechaRespuesta, or null if there is none), the assigned technician (name only) and plazoEntregaEstimado, the turnaround time the customer was given on the check-in receipt. Internal notes, signatures, photos, documents and device passwords are never returned.

If your CRM or phone system pulls up the customer record when a call comes in, use GET /clientes?telefono=<number>. It searches both the main and the secondary phone and ignores how the number is written: spaces, dashes, parentheses and your country code (+1 or 001). So “(555) 123-4567” finds a customer saved as “+1 555.123.4567”. At least 6 digits are required.

GET /clientes/{id}/resumen returns, in a single call, what a CRM usually shows on the customer record: totalReparaciones, reparacionesAbiertas (the device is still at the shop), porEstado, totalPresupuestado and totalPresupuestosAprobados (in the shop's currency, which comes in moneda), primeraReparacion, ultimaReparacion and ultimaActividad (the latest change on any of their tickets). It needs the Repairs resource, just like the tickets.

Lists accept page (from 1) and limit (25 by default, 100 at most; anything higher is capped at 100). The busqueda field searches name, surname, company name, tax id, email, code and phone.

120 requests per minute per key (plenty for a periodic sync; it stops a runaway loop). 10 active keys per organization. Lists return at most 100 records per page. If the organization is on the free plan with its monthly quota used up, creating customers is blocked just like in the app.

You can revoke one without breaking the others, and the list shows when each was last used.

Keep it in your tool's credential store (Make connections, n8n credentials, environment variables). If it ends up in a repository or a website, consider it leaked.

Revocation is immediate: the old key starts getting 401 CLAVE_REVOCADA. Update the new one in your tool and you are done.

The complete technical reference (paths, parameters, schemas and error codes) is published in an open format at /api/v1/openapi.json, no key needed. By default it comes in Spanish; add ?lang= with your language to get it translated (for example /api/v1/openapi.json?lang=en-US, ?lang=en or ?lang=ro). You can import it into Postman, Insomnia, Make or n8n to have every call ready.