Skip to content

Contratos de health checks

Jump to bottom
Hernan Lopez edited this page Oct 7, 2026 · 2 revisions

Contratos para health checks SOAP

Fecha de consulta: 2026-10-06. Este documento reúne los contratos publicados en los manuales oficiales y los WSDL servidos por homologación enlazados abajo. El coordinador de implementación invocó dummy de MTXCA en homologación: HTTP 200 y appserver/authserver/dbserver = OK; no se invocaron endpoints de producción. Los prefijos XML (a4, a5, a10, a13, ser) son alias ilustrativos; la URI de namespace es lo que identifica el contrato.

Endpoints y contratos dummy

Servicio WSAA service vigente Homologación (endpoint / WSDL) Producción (endpoint / WSDL) Operación / SOAPAction (SOAP 1.1) Request Response
Padrón A4 ws_sr_padron_a4 https://awshomo.afip.gov.ar/sr-padron/webservices/personaServiceA4 / agregar ?WSDL https://aws.afip.gov.ar/sr-padron/webservices/personaServiceA4 / agregar ?WSDL dummy; SOAPAction "" (WSDL homol.) <a4:dummy/> dummyResponse en http://a4.soap.ws.server.puc.sr/; contiene return y luego appserver, authserver, dbserver.
Constancia (antes A5) ws_sr_constancia_inscripcion https://awshomo.afip.gov.ar/sr-padron/webservices/personaServiceA5 / agregar ?WSDL https://aws.afip.gov.ar/sr-padron/webservices/personaServiceA5 / agregar ?WSDL dummy; SOAPAction "" (WSDL homol.) <a5:dummy/> dummyResponse en http://a5.soap.ws.server.puc.sr/; contiene return y luego appserver, authserver, dbserver.
Padrón A10 ws_sr_padron_a10 https://awshomo.afip.gov.ar/sr-padron/webservices/personaServiceA10 / agregar ?WSDL https://aws.afip.gov.ar/sr-padron/webservices/personaServiceA10 / agregar ?WSDL dummy; SOAPAction "" (WSDL homol.) <a10:dummy/> dummyResponse en http://a10.soap.ws.server.puc.sr/; contiene return y luego appserver, authserver, dbserver.
Padrón A13 ws_sr_padron_a13 https://awshomo.afip.gov.ar/sr-padron/webservices/personaServiceA13 / agregar ?WSDL https://aws.afip.gov.ar/sr-padron/webservices/personaServiceA13 / agregar ?WSDL dummy; SOAPAction "" (WSDL homol.) <a13:dummy/> dummyResponse en http://a13.soap.ws.server.puc.sr/; contiene return y luego appserver, authserver, dbserver.
MTXCA wsmtxca https://fwshomo.afip.gov.ar/wsmtxca/services/MTXCAService / agregar ?wsdl https://serviciosjava.afip.gov.ar/wsmtxca/services/MTXCAService / agregar ?wsdl dummy; SOAPAction http://impl.service.wsmtxca.afip.gov.ar/service/dummy (WSDL homol.) Body vacío: <soapenv:Body/> dummyResponse en http://impl.service.wsmtxca.afip.gov.ar/service/; hijos appserver, authserver, dbserver sin return.

Contratos adicionales de rutas ya inspeccionadas

Estos dos contratos se incluyen como referencia complementaria para checks existentes de facturación; no son lógica de emisión ni alteran el alcance de health-check. Los WSDL homol. de WSFE y WSFEX exponen FEDummy / FEXDummy, respectivamente, y SOAP 1.1/1.2.

Servicio WSAA service Homologación (endpoint / WSDL) Producción (endpoint / WSDL) Namespace / operación / SOAPAction Request / response
WSFEv1 wsfe https://wswhomo.afip.gov.ar/wsfev1/service.asmx / ?WSDL https://servicios1.afip.gov.ar/wsfev1/service.asmx / ?WSDL http://ar.gov.afip.dif.FEV1/; FEDummy; http://ar.gov.afip.dif.FEV1/FEDummy Request <tns:FEDummy/> vacío. Response wrapper FEDummyResponse y FEDummyResult; campos AppServer, DbServer, AuthServer, todos calificados en el namespace del schema.
WSFEXv1 wsfex https://wswhomo.afip.gov.ar/wsfexv1/service.asmx / ?WSDL https://servicios1.afip.gov.ar/wsfexv1/service.asmx / ?WSDL http://ar.gov.afip.dif.fexv1/; FEXDummy; http://ar.gov.afip.dif.fexv1/FEXDummy Request <tns:FEXDummy/> vacío. Response wrapper FEXDummyResponse y FEXDummyResult; campos AppServer, DbServer, AuthServer, todos calificados en el namespace del schema.

En los cinco contratos el namespace calificado se aplica al elemento de operación del request y al wrapper de respuesta. En los ejemplos documentados, return y los campos de estado aparecen sin namespace (no hay namespace por defecto que los califique). El sobre SOAP usa http://schemas.xmlsoap.org/soap/envelope/. Los valores de estado documentados son OK o ERROR; un OK solo confirma disponibilidad de esa respuesta, no autenticación o capacidad funcional de negocio.

Los manuales de Padrón exceptúan expresamente dummy del requisito de enviar token y sign; los cuatro WSDLs de homologación descargados declaran para esta operación soapAction="" y esquema elementFormDefault="unqualified". Por tanto, estos probes no necesitan solicitar ticket WSAA. El WSDL MTXCA consultado declara SOAP 1.1 document/literal, soapAction="http://impl.service.wsmtxca.afip.gov.ar/service/dummy" y mensaje dummyRequest sin partes. La URI .gov.ar del WSDL desplegado difiere de .gob.ar que aparece en el manual MTXCA v25; para invocación debe prevalecer el binding realmente desplegado.

A5 fue reemplazado por Constancia

El endpoint real conserva el sufijo personaServiceA5, pero el catálogo y manual actuales lo presentan como WS de Constancia de Inscripción, antes llamado ws_sr_padron_a5; el service que debe enviarse a WSAA es ws_sr_constancia_inscripcion. No confundir el nombre histórico de endpoint A5 con la identidad actual del servicio. El manual vigente también documenta getPersona_v2 y la incorporación opcional de fechaSolicitud en caracterizacion.

WSCPE: Carta de Porte Electrónica

El health check opt-in AddWscpeHealthCheck usa el dummy del WSDL fijado, sin ticket WSAA. Homologación: https://cpea-ws-qaext.afip.gob.ar/wscpe/services/soap; producción: https://cpea-ws.afip.gob.ar/wscpe/services/soap. El cuerpo SOAP está vacío y SOAPAction es https://serviciosjava.afip.gob.ar/wscpe/dummy. El wrapper de respuesta es DummyResp, namespace https://serviciosjava.afip.gob.ar/wscpe/. Dentro, respuesta contiene appserver, authserver y dbserver; estos cuatro elementos locales no tienen namespace. Se exige OK en todos los componentes. El resultado no prueba habilitación de una CUIT para emitir CPE. Fuentes: WSDL de homologación y procedencia de contratos.

WSAA no ofrece un método dummy

WSAA publica LoginCms en https://wsaahomo.afip.gov.ar/ws/services/LoginCms (homologación) y https://wsaa.afip.gov.ar/ws/services/LoginCms (producción), con operación SOAP loginCms y entrada CMS (in0) que contiene el TRA firmado. No hay operación dummy o health anónimo en el WSDL. Un GET de ?WSDL sirve únicamente para comprobar resolución/conectividad HTTP y disponibilidad del contrato; no valida el método loginCms, certificados, autorización ni salud de servicios dependientes. No enviar CMS ni realizar llamadas en una comprobación de disponibilidad sin credenciales/configuración explícitas.

Fuentes primarias

Implicaciones para probes de aplicación

  1. Usar host homologación o producción según configuración explícita; nunca derivar un host productivo para una ejecución local de prueba.
  2. Para A4, Constancia/A5, A10 y A13, construir dummy en el namespace de cada servicio. Para MTXCA, enviar body vacío con la operación definida por el WSDL.
  3. Validar el wrapper esperado y estados no vacíos; registrar appserver, authserver, dbserver sin asignarles interpretaciones cruzadas entre servicios.
  4. Para A4, Constancia/A5, A10 y A13, el WSDL homol. consultado declara SOAPAction vacío; MTXCA declara la URI .gov.ar indicada arriba. Ante un cambio de WSDL, releer el binding desplegado.
  5. WSAA puede tener un check separado de disponibilidad de WSDL/HTTP, no un check anónimo de su operación SOAP.

Clone this wiki locally