> ## Documentation Index
> Fetch the complete documentation index at: https://docs.spirii.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Charger validation
> Check that a charger model is supported before you commit hardware, and get a new model tested when you need one.
Charger validation is how Spirii tests a charger model on the platform: its core OCPP 1.6 integration, and separately, each advanced feature the model can support.
The public list of validated models, by manufacturer, model, firmware, and type.
## Overview
You can connect any OCPP 1.6-compliant charger to Spirii. Validation is what makes a model supported. Spirii's operations team has tested it on the platform, so the integration is one Spirii can guarantee.
A model is validated in two layers, and it can pass the first without the second:
* **Core integration.** The model connects and runs on the platform over OCPP 1.6. Every model on the supported list has passed this.
* **Feature validation.** Each advanced feature is validated separately. A model can be fully supported for charging with no features validated at all.
Check a model before you buy or install it. Finding out once the hardware is on site leaves you choosing between running without the features you planned on and waiting for the model to be validated.
## What's validated, and where to check
| Validation | Where to check |
| ---------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Core integration | The [supported chargers list](https://spirii.notion.site/Chargers-supported-in-Spirii-4ff0f9d78a914082874fb607fdaaae59), or [`GET /v2/chargeboxes/models`](/api-reference/chargeboxes-v2/fetches-a-list-of-supported-charge-box-models) |
| [Plug & Charge](/capabilities/access/plug-and-charge) | `plugAndChargeValidated` on the models API |
| [Firmware management](/capabilities/operation-monitoring/firmware-management) | `firmwareManagementValidated` on the models API |
| [Dynamic load management](/capabilities/energy-management/dynamic-load-management) | Your Spirii representative |
| [Scheduled charging](/capabilities/energy-management/scheduled-charging) | Your Spirii representative |
| [Grid balancing](/capabilities/energy-management/grid-balancing) | Your Spirii representative |
The list is the quickest way to look a model up. The API reads from the platform's own model records, so use it when you're checking from your own systems, and go by it if the two ever disagree. The list is maintained to match the API, but it's updated by hand, so a newly validated model can appear in the API first.
## How validation works
```mermaid theme={null}
flowchart TD
A("A partner, prospect, or manufacturer requests a model") --> B("Spirii prioritises it in the validation queue")
B --> C("Spirii obtains a test unit from the manufacturer")
C --> D("Spirii tests the core integration and advanced features")
D --> E{"Passes?"}
E -->|"Yes"| F("Added to the supported list")
E -->|"No"| G("The manufacturer provides a fix")
G --> D
```
Spirii's operations team runs validation on a test unit supplied by the manufacturer, and works with the manufacturer's team throughout. If a model needs changes, the fix comes from the manufacturer and the model is tested again.
Requests join a single queue that Spirii prioritises. A model that a partner or prospect needs for a real deployment usually comes ahead of one a manufacturer puts forward on its own.
### Firmware versions
Validation is for a model, tested on a specific firmware version, which the supported list records. For most purposes the model is what matters. The exception is energy management: a model validated in the past can fall out of compliance after a firmware update, so an earlier validation doesn't guarantee dynamic load management or scheduled charging on a newer version.
Spirii doesn't re-validate every model when a manufacturer releases new firmware. Where Spirii upgrades firmware on your behalf as a service, the new version is tested as part of that upgrade.
## Get a model validated
Ask your Spirii representative to put the model in the queue. Name the features you need as well as the model, since each feature is validated separately and core validation won't cover them.
For example, a fleet operator planning a depot around dynamic load management finds its preferred model on the supported list, validated for core integration only. It asks for DLM validation before ordering, because the model being on the list says nothing about how it handles DLM.
Manufacturers can also put a model forward to Spirii directly.
## Dependencies & limitations
* **Unvalidated models connect, without a guarantee.** Any OCPP 1.6-compliant charger can connect to the platform. On a model Spirii hasn't validated, Spirii can't guarantee the integration.
* **Feature results are only partly published.** The models API flags Plug & Charge and firmware management. Validation for dynamic load management, scheduled charging, and grid balancing is confirmed by your Spirii representative.
* **New firmware isn't validated automatically.** An earlier validation carries no guarantee for energy management features on a newer firmware version.
## Related
Once your model is confirmed, [Charger activation](/capabilities/connection/charger-activation) covers connecting it to the platform.
Create the charge box and bring a validated charger online.
The site-level capabilities that depend on feature validation.
Confirm every model in your fleet is validated before planning a migration.
List validated models and their Plug & Charge and firmware management flags.