verifactuPHP includes a built-in debug mode that prints real-time diagnostic messages to standard output as the library performs operations. When enabled, you can observe every stage of the request lifecycle — from the initial login token exchange through individual API calls to the construction of each model object. This makes it straightforward to verify that your data is being assembled correctly before it is submitted to AEAT. Debug mode is off by default. It is controlled through a pair of methods onDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/NemonInvocash/verifactu-php/llms.txt
Use this file to discover all available pages before exploring further.
ClienteVerifactu: setDebug(bool) and getDebug(). All output is produced by the private mostrarDebug() method, which checks the flag before printing — so there is no performance overhead when the mode is disabled.
Enabling debug mode
Instantiate the client as normal and then callsetDebug(true). Because the constructor triggers authentication immediately, the login attempt itself will not produce debug output unless you enable the mode before construction — which is not possible given the current API. All subsequent operations after the setDebug() call will emit diagnostic messages.
What gets logged
The following messages are printed to stdout while debug mode is active:| Trigger | Message |
|---|---|
| Successful login | Token recibido: <token-value> |
| Login returns no token | No se ha recibido token |
| Login HTTP error | Error en la solicitud: <guzzle-message> |
| Any successful API request (read/list operations) | Petición realizada correctamente followed by a print_r dump of the full response array. Write operations (altaEmisor, altaRegistroAlta, altaRegistroAnulacion) print only Petición realizada correctamente — no response dump, because they pass $requiereRetorno = false. |
nuevoEmisor() success | Emisor creado con éxito! followed by a print_r of getArrayData() |
nuevoDestinatario() success | Destinatario creado con éxito! followed by a print_r of getArrayData() |
nuevoTercero() success | Tercero creado con éxito! followed by a print_r of getArrayData() |
nuevoDesglose() success | Desglose creado con éxito! followed by a print_r of getArrayData() |
nuevoRegistroAlta() success | Registro Alta creado con éxito! followed by a print_r of getArrayData() |
nuevoRegistroAnulacion() success | Registro de anulacion creado con éxito! followed by a print_r of getArrayData() |
nuevaFacturaRectificada() success | Factura Rectificada creada con éxito! followed by a print_r of getArrayData() |
nuevaFacturaSustituida() success | Factura Sustituida creada con éxito! followed by a print_r of getArrayData() |
altaEmisor() success | Emisor dado de alta con éxito! |
altaRegistroAlta() success | Registro Alta dado de alta con éxito! |
altaRegistroAnulacion() success | Registro de anulacion dado de alta con éxito! |
| Any factory method error | Error al crear <resource>: <exception-message> |
Using debug mode during development
A typical development workflow is to enable debug mode after construction and then build your objects step by step, inspecting the output ofgetArrayData() at each stage to confirm the fields are correct before making a live submission.
Disabling debug mode
CallsetDebug(false) at any point to stop output. You can toggle the mode on and off within a single script if you only want to trace a specific portion of the execution.
Checking the current state
getDebug() returns the current value of the debug flag as a bool. Use this if you need to conditionally branch on whether debug mode is active in your own code.

