Skip to main content

Documentation 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.

VeriFactuAPI uses token-based authentication. Every request to the API must carry a valid Bearer token in its Authorization header. verifactuPHP handles this for you — when you instantiate ClienteVerifactu, the constructor immediately calls the private logIn() method, exchanges your credentials for a token, and stores it internally. By the time the constructor returns your object is ready to make authenticated API calls without any extra steps.

​
How it works

The login flow consists of three steps that happen transparently inside the constructor:
1

POST to /api/login

The constructor sends a JSON request to https://app.verifactuapi.es/api/login containing your email and password.
2

Token extracted and stored

The library reads the token field from the JSON response and stores it in the private $token property.
3

Bearer header attached to all requests

Every subsequent HTTP request made through the client automatically includes the header Authorization: Bearer {token}.

​
Instantiating the client

Pass your VeriFactuAPI account email and password directly to the constructor. Authentication happens immediately — there is no separate connect() or authenticate() call to make. 
use verifactuPHP\ClienteVerifactu;

$client = new ClienteVerifactu('you@example.com', 'your-password');

// The client is now authenticated and ready to use.
You need a VeriFactuAPI account to obtain credentials. Register at https://verifactuapi.es/.

​
Error handling

If the login request fails — due to incorrect credentials, a network error, or an unexpected server response — the constructor throws a standard PHP Exception. Wrap instantiation in a try/catch block to handle failures gracefully. 
use verifactuPHP\ClienteVerifactu;

try {
    $client = new ClienteVerifactu('you@example.com', 'your-password');
} catch (Exception $e) {
    // Authentication failed — inspect $e->getMessage() for details.
    echo 'Login failed: ' . $e->getMessage();
}
The exception message will be one of the following depending on where the failure occurred:
  • "Error inesperado: No se ha recibido token" — the server responded with HTTP 200 but did not include a token field in the JSON body. Internally, the library throws a plain Exception("No se ha recibido token") inside the try block, which is immediately caught by the outer catch (Exception $e) handler and re-wrapped with the "Error inesperado: " prefix before being re-thrown.
  • "Error en la solicitud: ..." — a Guzzle RequestException was thrown (e.g. HTTP 401, network timeout).
  • "Error inesperado: ..." — any other unexpected exception caught during the login attempt.

​
Token management

Once authenticated, you can read the stored token at any time using getToken(). This is useful if you need to inspect the token for debugging or pass it to another system. 
$token = $client->getToken(); // Returns the Bearer token string
The token is stored in the private $token property and is automatically included in the Authorization: Bearer header of every API request made by the client.

​
Updating credentials

If you need to switch the account credentials associated with an existing client instance — for example, to re-authenticate under a different user — use the setter methods. Note that calling these methods does not automatically trigger a new login; you would need to re-instantiate the client. 
$client->setEmail('newuser@example.com');
$client->setPassword('new-password');

// Re-instantiate to authenticate with the updated credentials.
$client = new ClienteVerifactu(
    $client->getEmail(),
    $client->getPassword()
);
You can also read back the currently configured values: 
$email    = $client->getEmail();    // Returns the configured email
$password = $client->getPassword(); // Returns the configured password
SSL certificate verification is disabled by default ('verify' => false) in all HTTP requests made by this library, including the login call. This is a library-level default intended to simplify local development and testing environments. In production, you should evaluate whether this setting is appropriate for your infrastructure and consider overriding the Guzzle client configuration if stricter TLS validation is required.

Build docs developers (and LLMs) love

Get started for freeTalk to us