Puedes escribirnos a contacto@relbase.cl

o llamarnos al +562 2869 1771

/ 600 086 6233

API REST · OAuth 2.0

Conecta tu sistema a relBase

Productos, clientes, inventario, entregas y documentos tributarios, desde tu propia aplicación. Autenticación OAuth 2.0, respuestas con estructura uniforme y webhooks para no consultar en bucle.

Autenticación
OAuth 2.0 · PKCE
Permisos
10 áreas
Escrituras
Idempotentes
# Listar productos · requiere el permiso products:read
curl -X GET "https://api.relbase.cl/api/v2/productos?page=2" \
  -H "Authorization: Bearer $ACCESS_TOKEN"

# {
#   "data": [ … ],
#   "meta": {
#     "code": 200,
#     "message": "success",
#     "current_page": 2,
#     "next_page": 3,
#     "total_pages": 8,
#     "total_count": 94
#   }
# }
200 · successpágina 2 de 8 · 94 resultados

Primeros pasos

De cero a tu primera llamada

Cada integración registra su propia Aplicación OAuth dentro de la cuenta de la empresa. El detalle de cada paso está en la guía de primeros pasos.

  1. 1

    Crea tu Aplicación OAuth

    Desde la cuenta de la empresa en relBase. Obtienes client_id y client_secret.

  2. 2

    Pide autorización

    Rediriges al usuario con los permisos que necesitas. Recomendado con PKCE S256.

  3. 3

    Canjea el código

    Intercambias el código recibido por un access_token y un refresh_token.

  4. 4

    Consume los endpoints

    Envías el token en Authorization. El token ya queda asociado a la empresa.

Alcance

Qué puedes integrar

Solicita únicamente los permisos que tu integración necesita. Si a tu token le falta uno, la respuesta es 403.

  • Productosreadwrite
  • Clientesreadwrite
  • Proveedoresreadwrite
  • Documentosreadwrite
  • Inventarioreadwrite
  • Entregasreadwrite
  • Usuariosreadwrite
  • Webhooksreadwrite
  • Bodegasread
  • Administraciónread

Las escrituras aceptan Idempotency-Key: repetir una solicitud con la misma clave devuelve la respuesta original en vez de ejecutar la operación dos veces. En inventario es obligatoria.

Emitir un documento

Esto es todo lo que necesitas enviar

Una boleta necesita el tipo de documento, las fechas y el detalle: ni siquiera exige cliente. El resto —cliente, referencias, descuentos, datos de exportación o de guía de despacho— es opcional y está en la referencia de endpoints.

Solicitud

# Boleta electrónica (39) con un producto
POST https://api.relbase.cl/api/v2/dtes

{
  "type_document": 39,
  "start_date": "08-09-2026",
  "end_date": "08-09-2026",
  "products": [
    {
      "product_id": 915,
      "price": 12990,
      "quantity": 2,
      "tax_affected": true,
      "unit_item": "UNID"
    }
  ]
}

Respuesta · recortada

{
  "data": {
    "folio": 10428,
    "sii_status": "sent_sii",
    "sii_status_name": "Enviado",
    "track_id": "3944821057",
    "amount_neto": 25980,
    "amount_iva": 4936,
    "amount_total": 30916,
    "pdf_file": "https://...",
    "xml_inter_file": "https://..."
    // ...
  },
  "meta": { "code": 200, "message": "success" }
}

Límites de uso

Dos controles independientes

Ambos responden 429 Too Many Requests al excederse.

Control 1 · Velocidad

Ventana de 60 segundos

300

solicitudes por empresa

Con token OAuth, además de 5 por segundo. Sin token, el tope es de 60 por minuto y 3 por segundo por IP.

El límite por segundo es más estricto en ráfagas: enviar varias solicitudes en paralelo puede devolver un 429 bastante por debajo del tope por minuto. Reparte las llamadas en el tiempo.

Control 2 · Volumen

Cuota diaria según tu plan

00:00

UTC · reinicio del contador

Cada plan incluye una cantidad distinta de solicitudes diarias. Al alcanzar el tope recibes un aviso por correo.

Puedes seguir tu consumo del día desde relBase, en Mi Cuenta → Consumo de API.

PlanSolicitudes por díaDTE mensuales
Despegue25.000hasta 1.000
Pyme50.000hasta 2.000
Corporativo100.000hasta 4.000

Consulta tu cupo exacto y tu consumo del día en relBase, en Mi Cuenta → Consumo de API, o compara los planes.

Monitorea tu consumo sin esperar el error

Cada respuesta incluye encabezados con el estado de tu cuota. Léelos para ajustar el ritmo a tiempo.

EncabezadoContenido
X-RateLimit-LimitLímite de la ventana vigente. Viene siempre.
X-RateLimit-RemainingSolicitudes que te quedan en esa ventana. Viene siempre.
X-RateLimit-Daily-LimitCupo diario de tu plan. Solo si tu plan tiene cuota configurada.
X-RateLimit-Daily-RemainingSolicitudes que te quedan hoy. Solo si tu plan tiene cuota configurada.
Retry-AfterEn un 429: segundos de espera, o hasta medianoche UTC si agotaste la cuota diaria.

Preguntas frecuentes

Lo que más nos preguntan

Si tu duda no está acá, escríbenos a contacto@relbase.cl.

Crear una Aplicación OAuth desde Mis Aplicaciones en relBase. Ahí obtienes tu client_id y client_secret, defines tus redirect_uri y marcas los permisos que necesitas. El client_secret se muestra una sola vez, al crearlo o al rotarlo: guárdalo en ese momento.

El access_token expira a los 15 minutos. Renuévalo con tu refresh_token antes de que venza: cada intercambio devuelve un par nuevo y revoca el anterior, así que guarda siempre el último que recibas. Si el refresh_token fue revocado, tendrás que volver a autorizar desde cero.

Es muy recomendable en todo flujo de authorization_code, sobre todo en clientes públicos. El método soportado es S256: genera un code_verifier de 43 a 128 caracteres URL-safe y envía su hash como code_challenge. Si envías el code_challenge, el code_verifier pasa a ser obligatorio al canjear el código.

Dentro de un iframe no: la pantalla se sirve con X-Frame-Options: DENY para evitar clickjacking. Ábrela en un popup y recibe el código por postMessage, o haz un redirect top-level desde tu backend.

Recibes 429 Too Many Requests. Los límites de velocidad tienen dos ventanas simultáneas: por minuto y por segundo. A eso se suma la cuota diaria de tu plan. Respeta el encabezado Retry-After, reintenta con espera progresiva y reparte las solicitudes en el tiempo en vez de enviarlas en ráfaga.

Porque la API trabaja con los identificadores internos de relBase, no con los de tu sistema ni con el SKU o el RUT. Un product_id es el ID del producto en relBase, y lo mismo vale para customer_id, city_id, commune_id, ware_house_id o type_payment_id. Los obtienes de sus endpoints: /productos, /clientes, /ciudades, /comunas, /bodegas y /forma_pagos. Es la confusión más común al empezar: sirve pensar que primero mapeas tu catálogo y recién después emites.

No, y es lo más importante que puedes hacer para que la integración funcione bien. Guarda en tu sistema el ID de relBase junto al tuyo —una tabla de equivalencias— y sincronízala cuando crees o modifiques productos y clientes, no en cada venta. Resolver los IDs en cada emisión multiplica las llamadas, gasta tu cuota diaria y agrega latencia justo en el momento de cobrar. Dos atajos que ayudan: en las boletas el cliente es opcional, y cuando sí necesitas uno puedes enviar el objeto customer completo en vez de customer_id — relBase lo reutiliza si ya existe o lo crea en el momento.

No. Los documentos que emites por la API descuentan del mismo cupo mensual de DTE de tu plan, el que ya compartes con relBase y con tus otros canales de venta. La API no tiene un tope de DTE propio: lo único que limita por separado son las solicitudes por día, y esas se cuentan por llamada, no por documento.

Envía el encabezado Idempotency-Key en las escrituras. Si repites la solicitud con la misma clave, recibes la respuesta original en vez de ejecutar la operación de nuevo. En inventario es obligatoria; en webhooks y proveedores está soportada.

Suscríbete a webhooks y recibe los eventos en tiempo real. Es preferible a hacer polling: consume menos de tu cuota diaria y te enteras antes.

Porque los permisos se forman con dos capas y una llamada necesita las dos. La primera son los scopes de tu Aplicación OAuth: lo que la integración pidió y el usuario aprobó, por ejemplo documents:write. La segunda es el perfil del usuario que autorizó: su rol dentro de la empresa en relBase, con los permisos que tenga asignados. Lo que puedes hacer es la intersección de ambas. Si a tu token le falta un scope, el detalle dirá Missing scopes; si el scope está pero el usuario no tiene ese permiso en su perfil, dirá authorization_failed. En ese caso no cambies la integración: pídele a un administrador de la empresa que ajuste el perfil del usuario, o vuelve a autorizar con uno que sí tenga el permiso.

Usa el código HTTP, no el texto de meta.debug_info, que varía según el caso. 403 cuando a tu token le falta un permiso, el país no está habilitado o el usuario no tiene el rol necesario. 401 cuando el token es inválido, expiró o no se pudo resolver la empresa.

La fecha y hora UTC del request, el endpoint y método, el X-Request-Id que enviaste, tu client_id, la empresa involucrada, el status HTTP recibido y el meta completo de la respuesta. Con eso podemos rastrear la solicitud de extremo a extremo.

Empieza por la guía de primeros pasos

Crea tu Aplicación OAuth, genera tu token y haz tu primera llamada. Después, la referencia completa de cada endpoint está en apidocs.relbase.cl.