DTEM API 🔗

Integra DTEM usando una simple y poderosa API.

API Docs Permite Automatizar los procesos de Factura Electrónica con una simple y poderosa API. La API a utilizar es de tipo REST.

API resources disponibles 🔗

Para ver una Lista de los recursos disponibles de la API se debe ver API resources.

Uso Básico 🔗

Las llamadas a la API deben tener el prefijo del contexto (Nombre app) correspondientes a emisión o recepción de DTE. Por ejemplo

/dtem/emision/Documento/

Ejemplo de una llamada válida utilizando con URL:

curl "https://www.example.com/dtem/emision/Documento"

Autenticación 🔗

La mayoría de las APIS requieren autentificación, o sólo retornarán datos publicos cuando no se provea autentificación.

Para aquellos casos donde no es requerida la autenticación, será mensionado en la documentación. para cada endpoint. Por ejemplo:

Formas de autentificación 🔗

• OAuth2 tokens
• Personal access tokens
• Session cookie

Si la información de autenticación no es válida o se omite, aparecerá un mensaje de error devuelto con el código de estado 401:

{
  "message": "401 Unauthorized"
}

Ejemplo de uso del token OAuth2 en un encabezado:

curl --header "Authorization: Bearer OAUTH-TOKEN" https://www.example.com/dtem/emision/Documento

Personal access tokens

Puede usar un token de acceso personal para autenticarse con la API pasándolo en el parámetro private_token o el encabezado Private-Token.

Session cookie 🔗

When signing in to the main GitLab application, a _gitlab_session cookie is set. The API will use this cookie for authentication if it is present, but using the API to generate a new session cookie is currently not supported. The primary user of this authentication method is the web frontend of GitLab itself, which can use the API as the authenticated user to get a list of their projects, for example, without needing to explicitly pass an access token.

You can also use personal access tokens with OAuth-compliant headers:

curl --header "Authorization: Bearer <your_access_token>" https://www.example.com/dtem/emision/Documento

Códigos de estado 🔗

La API está diseñada para devolver diferentes códigos de estado según el contexto y acción. De esta forma, si una solicitud produce un error, la persona que llama puede obtener comprensión de lo que salió mal.

La siguiente tabla ofrece una descripción general del comportamiento general de las funciones de la API.

La siguiente tabla muestra los posibles códigos de retorno para solicitudes a la API.

Validación de datos e informes de errores. 🔗

Al trabajar con la API, puede encontrar errores de validación, en cuyo caso la API responderá con un estado HTTP 400. Tales errores aparecen en dos casos:

• Falta un atributo requerido de la solicitud de API, por ejemplo, no se envia el rut del receptor del documento.
• Y cuando un atributo no pasó la validación, por ejemplo, la razón social del receptor es demasiado larga.

Cuando falta un atributo requerido, obtendrá algo como:

HTTP/1.1 400 Bad Request
Content-Type: application/json
{
    "message":"400 (Bad request) \"title\" not given"
}

Cuando se produce un error de validación, los mensajes de error serán diferentes. Ellos traerán los detalles de los errores de validación:

HTTP/1.1 400 Bad Request
Content-Type: application/json
{
     "message": {
         "razonrecep": [
             "is too long (maximum is 255 characters)"
         ]
     }
 }