Qué es
SOAP es un estilo de API: el formal y antiguo, frente al moderno de hoy. Como toda API, conecta dos sistemas para que se pidan datos sin que nadie teclee nada; lo suyo es la rigidez con la que exige que se pidan.
Cada solicitud y cada respuesta viajan como un documento XML de estructura fija: un sobre que lo envuelve todo, un encabezado con los datos de control del mensaje y un cuerpo con la petición. El contrato se publica de antemano: si un dato falta o va fuera de lugar, se rechaza el mensaje entero.
En palabras de contador
Una forma preimpresa se llena campo por campo, en el orden que ella marca. No basta con que el dato sea correcto: tiene que ir en su casilla y en su renglón. Si una queda vacía o el dato se escribió en la de junto, no te devuelven esa hoja: te regresan el paquete completo, incluida la parte que sí servía.
Así trabaja SOAP. Sigue vivo donde la forma pesa tanto como el fondo: dependencias, bancos y sistemas que llevan décadas operando. Ahí lo ceremonioso es la característica, no el estorbo.
Ejemplo aplicado
Un lote de consultas que regresa sin respuesta. Se mandan a revisar los comprobantes recibidos del mes y una de las solicitudes sale con un dato en blanco. Esa consulta no regresa parcial: regresa sin nada, y hay que rearmarla antes de cerrar el papel de trabajo.
El estatus antes de liberar un pago. Antes de pagarle a un proveedor se pregunta si su comprobante sigue vigente. La consulta se arma con la estructura que el servicio exige y la respuesta se guarda con su fecha y su hora.
Un sistema empresarial o bancario heredado. El ERP del cliente o su banca empresarial expone sus datos por SOAP porque así se construyó hace quince años: te conectas por donde abre la puerta, no por donde preferirías.
Para qué sirve en un despacho
- Consultar de forma automática el estatus de comprobantes ante la autoridad.
- Procesar consultas repetitivas sin teclearlas en un portal.
- Conectar el sistema contable con un ERP o una banca heredada.
- Conservar constancia de qué se preguntó y qué se contestó.
Riesgos o limitaciones
SOAP es exigente y poco tolerante: un campo de más o uno faltante bastan para que rechace el mensaje completo. Hay servicios de este estilo que piden además certificados propios, con su propia renovación que atender. Y pueden no contestar: sin respuesta no hay dato, y el pendiente regresa al escritorio.
Tampoco leas la respuesta como verdad permanente: refleja el estado del momento en que se preguntó. Lo estricto del formato no elimina el riesgo de trabajar con información vencida.
Buena práctica
Armar los mensajes no te toca a ti. Lo que sí te toca es preguntarle dos cosas a quien te integre el servicio: qué hace el proceso cuando la autoridad no contesta, y cómo te enteras de que no contestó. Uno que reintenta y avisa vale más que uno que deja el tablero en blanco.
Guarda la respuesta completa con fecha y hora, no solo la conclusión: mostrar qué contestó el servicio y cuándo pesa más que tu palabra.
Preguntas frecuentes
¿SOAP está obsoleto? No en la práctica: para proyectos nuevos casi nadie lo elige, pero donde ya opera se queda porque migrarlo cuesta.
¿Puedo consultarlo desde el navegador? No como una página: espera un mensaje armado con su estructura, y quien consulta es un programa, no una persona en un portal.
¿Qué cambia frente al estilo moderno de API? Aquí manda el contrato del servicio y la respuesta viene envuelta en XML, que hay que interpretar antes de mostrar.
Términos relacionados
Conexión NexFiscal
Cada vez que NexBot revisa un comprobante arma uno de estos mensajes: pregunta el estatus del CFDI por el servicio SOAP de la autoridad, con la estructura que ese servicio exige, y espera la respuesta antes de concluir nada. Por eso su dictamen no dice solo lo que trae el archivo, sino lo que contestó la autoridad y en qué momento lo contestó. Esa constancia es la que te sirve cuando alguien cuestiona el estatus meses después.
Escrito y revisado por Ernesto Sobrino, contador.
Última revisión: 24 de agosto de 2026.