Factura afecta (33)

Campos, request por los 3 canales programáticos, response 202 y la tabla completa de estados SII — la referencia canónica de la familia de facturas.

El tipo_dte 33 es la Factura Electrónica afecta a IVA — el caso más común para SpAs, empresas de servicios profesionales y comercio B2B. Esta es la página canónica de campos de la familia de facturas: Factura exenta (34), Nota de Crédito (61) y Nota de Débito (56) documentan solo sus diferencias respecto de esta página.

Campos del request

POST /api/v1/dtes acepta este body para tipo 33:

Campo	Tipo	Requerido	Descripción / constraint
`tipo_dte`	`number`	sí	`33` para factura afecta
`rut_emisor`	`string`	sí	RUT canónico `BODY-DV` sin puntos (`76123456-0`); el DV se valida módulo 11
`receptor.rut`	`string`	sí	Mismo formato canónico (`11111111-1`)
`receptor.razon_social`	`string`	sí	Mínimo 1 carácter después de trim — espacios solos rechazan
`receptor.giro`	`string`	sí (33/34)	Giro del receptor; obligatorio y no vacío para 33 y 34
`receptor.direccion`	`string`	sí (33/34)	Dirección del receptor; obligatoria y no vacía para 33 y 34
`receptor.comuna`	`string`	sí (33/34)	Comuna del receptor; obligatoria y no vacía para 33 y 34
`fecha_emision`	`string`	sí	Formato `YYYY-MM-DD`
`items`	`array`	sí	Entre 1 y 60 items
`items[].nombre`	`string`	sí	Mínimo 1 carácter
`items[].cantidad`	`int`	sí	Entero
`items[].precio_unitario`	`int`	sí	Pesos CLP, sin decimales
`items[].exento`	`boolean`	sí	La 33 admite mezclar items afectos y exentos
`items[].monto_item`	`int`	sí	Total de la línea en CLP
`forma_pago`	`1 \| 2 \| 3`	sí (33/34)	Forma de pago: `1` Contado, `2` Crédito, `3` Sin costo. Obligatorio para 33 y 34. La UI pre-selecciona Crédito (`2`)
`references`	`array`	no	Máximo 40. En la 33 solo referencias comerciales (`orden_compra`, `contrato`, `hes`), sin `cod_ref` — las referencias correctivas pertenecen a NC y ND
`monto_neto`	`int`	no	Si lo mandas, debe igualar la suma de items afectos
`monto_exento`	`int ≥ 0`	no	Si lo mandas, debe igualar la suma de items exentos
`iva`	`int`	no	19% sobre el neto
`monto_total`	`int`	no	Debe igualar `monto_neto + iva + monto_exento`
`certificate_id`	`string` (UUID)	no	Certificado digital específico; por defecto el activo de la organización
`sii_env`	`"cert" \| "prod"`	no	Default `"cert"` (maullin, sandbox del SII)

Los montos son opcionales porque Notta los calcula desde los items. Si los mandas y no cuadran, el endpoint responde 400 con código validation_failed y el detalle campo por campo en issues[].

Request

Puedes emitir por los 3 canales programáticos (API, CLI, MCP) + el dashboard. El mismo request en los tres programáticos:

Disponibilidad

@notta/cli y @notta/mcp están en proceso de publicación en npm. El camino ejecutable hoy es curl con tu API key — el dashboard y la API cubren el flujo completo mientras tanto.

curl -X POST https://app.notta.cl/api/v1/dtes \
  -H "Authorization: Bearer ntt_cert_..." \
  -H "X-Cert-Id: 01957a91-0b50-7000-8000-cccc00000001" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "tipo_dte": 33,
    "rut_emisor": "76123456-0",
    "receptor": {
      "rut": "11111111-1",
      "razon_social": "Cliente Ejemplo SpA",
      "giro": "Comercio",
      "direccion": "Av Siempre Viva 123",
      "comuna": "Santiago"
    },
    "forma_pago": 2,
    "fecha_emision": "2026-05-13",
    "items": [{
      "nombre": "Consultoría mayo 2026",
      "cantidad": 5,
      "precio_unitario": 50000,
      "exento": false,
      "monto_item": 250000
    }]
  }'

El X-Cert-Id es el id de tu certificado (paso 1 del quickstart o dashboard).

Response

El endpoint responde 202 Accepted — la emisión es asíncrona. El DTE queda queued, y la transición a EPR ocurre tras firma + envío al SII (típicamente 2-15 segundos).

{
  "id": "01957a91-0b50-7000-8000-000000000001",
  "status": "queued",
  "folio": 1234,
  "tipo_dte": 33,
  "rut_emisor": "76123456-0",
  "rut_receptor": "11111111-1",
  "monto_neto": 250000,
  "monto_exento": 0,
  "iva": 47500,
  "monto_total": 297500,
  "sii_env": "cert",
  "sii_status": "queued",
  "fecha_emision": "2026-05-13",
  "links": {
    "self": "/api/v1/dtes/01957a91-0b50-7000-8000-000000000001",
    "pdf": "/api/v1/dtes/01957a91-0b50-7000-8000-000000000001/pdf",
    "xml": "/api/v1/dtes/01957a91-0b50-7000-8000-000000000001/xml",
    "events": "/api/v1/dtes/01957a91-0b50-7000-8000-000000000001/events"
  }
}

Para seguir el estado, consulta links.self con GET. Si el SII demora, fuerza una re-consulta con POST /api/v1/dtes/{id}/refresh-status. links.events apunta a un endpoint aún no habilitado — para seguir el estado usa links.self o refresh-status.

Estados SII

status y sii_status traen el mismo valor. Los posibles:

Estado	Significado
`queued`	Encolado, aún sin firmar
`sending`	Firmado, enviando al SII
`awaiting_sii`	Recibido por el SII, esperando resultado
`SOK`	Schema validado por el SII (transitorio — el procesamiento sigue asíncrono)
`CRT`	Carátula validada (transitorio)
`EPR`	Envío procesado y aceptado (terminal de éxito)
`RPR`	Aceptado con reparos a nivel de envío (revisar `sii_glosa`)
`aceptado_con_reparos`	Documento aceptado con observaciones (revisar `sii_glosa`)
`RFR`	Rechazado por error de firma (terminal)
`RCT`	Rechazado por error de carátula (terminal)
`RSC`	Rechazado por error de schema (terminal)
`stuck`	El polling agotó reintentos sin resultado terminal — requiere revisión

Idempotency

Todo POST exige el header Idempotency-Key (UUIDv7 recomendado); sin él, el endpoint responde 400 con código idempotency_key_missing. Si la misma key llega dos veces, retorna el resultado de la primera operación en lugar de duplicar el DTE.

CLI y MCP generan keys frescas automáticamente.

Próximos pasos

Nota de Crédito (61) — corrige o anula una factura ya aceptada por el SII.
Referencia API de DTEs — todos los endpoints de /dtes: list, detail, PDF, XML y refresh-status.
Errores — el shape uniforme de error (code, hint, next_action) y cómo manejarlo.