ISFactura

Información de un NIT

Consulta en la DIAN la razón social y el correo registrados para una identificación.

GET /api/nit/{nit}/{tddocumento?}

Es la ruta de la función, y no cambia entre ambientes. La URL base con la que la ejecutas aquí es la del sandbox. Es la URL del sandbox y no corresponde a la etapa productiva de la integración. La URL base de producción se te entrega al adquirir el servicio.
¿Es tu primer contacto con esta parte de la plataforma? Empieza por Consultas generales, donde se explica qué documentos existen, cómo se arma el JSON y qué valida el servidor antes de que ejecutes nada.

Devuelve los datos que la DIAN tiene registrados para una identificación: la razón social y el correo de notificación. Es la consulta con la que se valida un receptor antes de facturarle, en lugar de descubrir el dato equivocado cuando la DIAN rechaza el documento.

El tipo de documento es opcional. Si no se envía, se buscan los tipos que puede tener la identificación; conviene enviarlo cuando el tercero no es un NIT, porque una cédula y un NIT con los mismos dígitos son terceros distintos para la DIAN.

La respuesta devuelve el tddocumento que la DIAN reconoció, que puede no ser el que se consulto: ese es el que hay que usar después en el documento electrónico.

Cómo resuelve el sandbox esta función

Consultas a la DIAN

Las consultas comparten la misma forma: los datos van en la ruta, no llevan cuerpo y no gastan consecutivos ni dejan nada reportado en la DIAN. Por eso son las funciones con las que conviene empezar: se pueden repetir tantas veces como haga falta. La consulta se resuelve ante la DIAN, y si hay registro responde 200 con los datos encontrados. Si no hay registro también responde 200, con los mismos campos vacíos: la ausencia de resultado también es un resultado, y una integración que espere un 404 para decidir «no encontrado» no lo va a recibir nunca. **La consulta del XML de un documento es la excepción**: esa sí responde 404, y tiene su propio diagrama.

Consultas a la DIANLas consultas comparten la misma forma: los datos van en la ruta, no llevan cuerpo y no gastan consecutivos ni dejan nada reportado en la DIAN. Por eso son las funciones con las que conviene empezar: se pueden repetir tantas veces como haga falta. La consulta se resuelve ante la DIAN, y si hay registro responde 200 con los datos encontrados. Si no hay registro también responde 200, con los mismos campos vacíos: la ausencia de resultado también es un resultado, y una integración que espere un 404 para decidir «no encontrado» no lo va a recibir nunca. **La consulta del XML de un documento es la excepción**: esa sí responde 404, y tiene su propio diagrama.SÍNOLa consulta llega con susdatos en la rutaConsultaante la DIAN¿Hay registro?200Los datos encontrados200Los mismos campos,vacíosLEYENDAInicio y finPasoDecisión

Desliza el diagrama para verlo completo.

Ver la fuente Mermaid del diagrama 
flowchart TD
    A(["La consulta llega con sus datos en la ruta"]) --> B["Consulta ante la DIAN"]
    B --> C{"¿Hay registro?"}
    C -- Sí --> D(["200 · los datos encontrados"])
    C -- No --> E(["200 · los mismos campos, vacíos"])

Datos que recibe

Encabezado

DatoTipoDescripción
Authorization*string

Credencial de la petición, con el prefijo Bearer. En el sandbox la pone el portal por ti y la renueva antes de cada ejecución; en producción la controlas tú, con el JWT que genera tu integración a partir de sus credenciales — ver Credenciales y JWT.

Ejemplo:Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6...

Ruta

DatoTipoDescripción
nit*string

Identificación del tercero, sin el dígito de chequeo y sin puntos ni guiones.

Ejemplo:810000630

tddocumentonumber

Tipo de identificación del tercero. Si se omite, se buscan los tipos posibles.

Ejemplo:31

Ver los 12 valores admitidos
  • 11 · Registro civil
  • 12 · Tarjeta de identidad
  • 13 · Cedula de ciudadanía
  • 21 · Tarjeta de extranjería
  • 22 · Cedula de extranjería
  • 31 · NIT
  • 41 · Pasaporte
  • 42 · Documento de identificación extranjero
  • 47 · PEP — Permiso Especial de Permanencia
  • 48 · PPT — Permiso por Proteccion Temporal
  • 50 · NIT de otro país
  • 91 · NUIP

 Ejecutar la función

Ambiente de habilitación de la DIAN · la consulta no modifica nada ni gasta consecutivos

 Lo que se envía

 Datos de la ruta
Sin escoger no viaja: el segmento desaparece de la ruta

El detalle de cada dato, con sus valores admitidos, está en Datos que recibe.

Se enviara GET https://proveedortecnologico-sandbox.azurewebsites.net/api/nit/810000630/31

Es la URL del sandbox y no corresponde a la etapa productiva de la integración. La URL base de producción se te entrega al adquirir el servicio. Lo que si es igual en los dos es la ruta.

 Respuesta

Aquí queda tu ejecución: la ruta que viajó, el cuerpo que enviaste, el código con el que respondió el sandbox y el tiempo discriminado. Un error también queda: es lo que se necesita junto al cuerpo que lo produjo.

 Exportar a Postman

Descarga esta función como colección de Postman, con los valores que tienes ahora en la barra y tu credencial vigente: se importa y se envía sin configurar nada.

Respuestas

  • 200 Entrega en respuesta.datos el nit, el tddocumento que reconoció la DIAN, el nombre y el email registrados.
  • 401 La credencial no llegó, ya venció, o la cuenta no tiene perfil registrado en el sandbox. En producción es además el código con el que se rechaza un emisor que la credencial no tiene autorizado — ver Credenciales y JWT.
  • 500 La DIAN no respondió la consulta.

Errores frecuentes

  • 401 El desarrollador autenticado no tiene un perfil registrado en el sandbox

    La cuenta se autenticó pero nunca completó el registro de desarrollador. Se resuelve diligenciando el perfil desde el portal.

  • 500 No fue posible consultar el tercero en la DIAN

    La DIAN no está respondiendo. Se reintenta; la consulta no tiene efectos colaterales.

Ten en cuenta

  • En el sandbox la respuesta llega enmascarada, y en producción no. nombre y email salen con la primera mitad de cada palabra visible y el resto reemplazado por █. Son datos de terceros reales que la DIAN tiene registrados, y el sandbox lo usa cualquier desarrollador: enmascararlos es lo que permite publicar la consulta. La estructura, los campos y los tipos de la respuesta son exactamente los mismos.
  • Lo que eso implica al integrar: el █ no es un carácter válido ni en un nombre ni en un correo, de modo que aquí no se puede validar el formato del email ni usar el nombre como razón social de un documento de prueba. Lo que sí se puede comprobar es lo que esta consulta responde de verdad: si el tercero existe y qué tddocumento le reconoció la DIAN. En producción los dos campos llegan completos y tal como están registrados, sin ningún carácter de relleno.
  • Un tercero que la DIAN no tiene registrado no es un error: responde 200 con el nombre y el correo vacíos. Hay que evaluar el contenido, no solo el código HTTP.
  • La consulta se resuelve contra el ambiente de habilitación, donde el catálogo de terceros de la DIAN no coincide con el de producción: un NIT real puede responder vacío aquí y con datos allá.
  • En producción se consume con la misma ruta y el mismo contrato, cambiando la credencial del sandbox por el JWT de tu integración.