Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/tutosrive/factus_challenge/llms.txt

Use this file to discover all available pages before exploring further.

This endpoint removes an electronic invoice from the Factus platform using its reference code. Deletion is only permitted for invoices that have not yet been sent to DIAN — that is, invoices with status === 0. Once an invoice has been validated and transmitted to the DIAN (status === 1), it forms part of the official fiscal record and cannot be deleted. The backend forwards the request to DELETE /v1/bills/destroy/reference/{reference_code} on the Factus API.

Endpoint

DELETE /factura/:reference_code

Path Parameter

reference_code
string
required
The auto-generated reference code of the invoice to delete (e.g., J2M4V6S3R6). This 10-character alphanumeric string is returned in the bill.reference_code field of both the create and get-single-invoice responses, and in the reference_code field of each item in the list response.

Request

No request body is required. The backend maps the reference_code path segment directly into the Factus API URL and sends a DELETE request with the stored Bearer token.

Constraints

Only invoices with status === 0 (not yet sent to DIAN) can be deleted. If you attempt to delete a validated invoice (status === 1), the Factus API will reject the request. This constraint is typically enforced in the frontend before this endpoint is even called, but the Factus API itself will also reject such attempts.
  • The reference_code must match exactly — it is case-sensitive.
  • There is no soft-delete or recycle bin; deletion is permanent on the Factus side.

Response

200 — Success

Returns the success message from the Factus API.
status
number
Always 200 on success.
message
string
The raw success message returned by the Factus API (e.g., "Factura eliminada correctamente").
{
  "status": 200,
  "message": "Factura eliminada correctamente"
}

500 — Internal Server Error

Returned when the Factus API call fails (network failure, misconfiguration, or an unhandled exception). Two distinct shapes are possible depending on where the error originates: Shape A — upstream call failure (from request_fact internal catch):
{
  "status": 500,
  "error": "ERROR INTERNO",
  "data": {}
}
Optional extra fields may also appear: message (Axios error message), code (Axios error code), error_name (error class name). Shape B — controller-level exception:
{
  "status": 500,
  "messaje": "Hubo un error al intentar realizar la solicitud",
  "error": {}
}
The messaje key (with a j) in Shape B is a known typo in the backend source — handle it as-is when parsing error objects. Shape A uses error as a plain string ("ERROR INTERNO"), not an object.

Code Examples

curl -X DELETE http://localhost:3000/factura/J2M4V6S3R6 \
  -H "Accept: application/json"

Build docs developers (and LLMs) love