REST API

Use DTEM REST API para automatizar Factura Electrónica

DTEM API

Integra DTEM usando una simple y poderosa API.

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

Recursos Disponibles

Recurso Descripción
Documentos API para gestión de DTEs (Facturas, Notas, etc.)
Boletas API específica para Boletas Electrónicas
Recepción API para recepción y procesamiento de DTE

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.

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.

Metodos Descripción
GET Accesa uno o mas recursos y retorna el resultado como JSON.
POST Retorna 201 Created Si el recurso es creado correctamente, y devuelve el recurso recién creado como JSON.
GET / PUT Retorna 200 OK Si se accede al recurso o si se modifica con éxito. El resultado (modificado) se devuelve como JSON.
DELETE Retorna 204 No Content Si el recurso se eliminó correctamente.

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

Valores Retornados Descripción
200 OK Cuando las solicitudes GET o PUT fueron exitosas, y los recursos en sí mismos se devuelven como JSON.
204 No Content Como el caso de DELETE u otros, cuando el servidor ha cumplido con éxito la solicitud y no hay contenido adicional para enviar en el cuerpo de la carga útil de respuesta.
201 Created Cuando la solicitud POST se realizó correctamente, y el recurso creado se devuelve como JSON.
304 Not Modified Indica que el recurso no se ha modificado desde la última solicitud.
400 Bad Request Cuando falta un atributo requerido de la solicitud de API, por ejemplo, no se envia tipo del documento a crear.
401 Unauthorized Cuando el usuario no está autenticado, se necesita un token de usuario válido.
403 Forbidden Cuando la solicitud no está permitida, por ejemplo, el usuario no puede eliminar un documento ya enviado al SII.
404 Not Found Cuando No se pudo acceder a un recurso, por ejemplo, no se pudo encontrar un documento a modificar.
405 Method Not Allowed Metodo o Solicutud no soportada. Cuando se trata de usar un metodo no definido para la API.
409 Conflict Existe un recurso en conflicto, por ejemplo, crear un documento con que ya existe
412 Indica que la solicitud fue denegada. Puede suceder si se proporciona el encabezado para modificar, al intentar eliminar un recurso, que se esta modificando en el medio.
422 Unprocessable La entidad no pudo ser procesada.
500 Server Error Al manejar la solicitud, algo salió mal en el lado del servidor.

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)"
         ]
     }
 }
Emisión

DTEM REST API Emisión

Recepción

DTEM REST API Recepción