GET /v1/receptores y usá el resultado para armar el objeto receptor de POST /v1/de/emitir.
Todas las operaciones (salvo la consulta al padrón) están filtradas por tenant: un receptor pertenece siempre al tenant que lo creó, y un GET/PATCH/DELETE sobre un id de otro tenant devuelve 404 (no existe, no que no tenés permiso).
Tipo de operación (tipo_operacion)
Cada receptor tiene un tipo_operacion que determina qué campos son obligatorios:
GET /v1/receptores
Listado paginado con búsqueda fuzzy en nombre, nombre de fantasía y RUC.200:
POST /v1/receptores
Crea un receptor en el catálogo del tenant.200 devuelve el receptor creado con el mismo shape que el listado.
Si ya existe un receptor con el mismo
ruc en tu catálogo (solo aplica a tipo_operacion: 1 o 3, que sí guardan RUC), la API devuelve 409 con el id del receptor existente en el mensaje — no se crea un duplicado.GET /v1/receptores/
Devuelve un receptor por id.404 si no existe o pertenece a otro tenant.
PATCH /v1/receptores/
Actualización parcial — solo los campos presentes en el body se modifican. Acepta los mismos campos quePOST, todos opcionales.
Si el PATCH incluye tipo_operacion (cambio de tipo de cliente), tenés que enviar en la misma request todos los campos obligatorios del tipo nuevo — e-Miti no valida contra el estado ya guardado en BD. Al cambiar de tipo, los campos que no aplican al tipo nuevo se limpian automáticamente (por ejemplo, pasar de no domiciliado a contribuyente borra documento_tipo/documento_numero y fija codigo_pais: "PRY").
404 si no existe.
DELETE /v1/receptores/
Soft-delete: marca el receptor comoactivo: false sin borrar la fila (los DE ya emitidos guardan un snapshot del receptor, no una referencia viva).
Respuesta 200:
404 si el receptor no existe.
GET /v1/receptores/padron/
Proxy del padrón público de contribuyentes (turuc.com.py) para consultar un RUC antes de darlo de alta. Requiere autenticación (como el resto de la API) aunque no consulta datos del tenant.200: