AFIR Article 20 EV-Charging Telemetry — One API Across Europe

The Alternative Fuels Infrastructure Regulation (AFIR) — (EU) 2023/1804 — is one of the more consequential pieces of European mobility law in years. It mandates minimum charging coverage on the TEN-T network, payment-method requirements, and crucially for any developer building EV-aware software, Article 20: live charging-station telemetry exposed via each Member State's National Access Point in DATEX II.

If you build a routing app, a fleet-electrification dashboard, a roaming/payment platform, or a charging-network analytics tool, AFIR Article 20 is the most useful regulation that's ever been written for you. The catch: every Member State is implementing it on its own timeline, in its own profile, behind its own NAP. Here's the picture as we see it from NAPSPAN, where we aggregate AFIR data across the continent into a single API.

What Article 20 Actually Requires

The relevant text mandates that Charge Point Operators (CPOs) make the following static and dynamic data available, free of charge, in machine-readable form, via the NAP:

Static (one-shot, slowly-changing):

• Geographic coordinates of the charging station and each charge point
• Number of connectors per station
• Connector types (CCS, CHAdeMO, Type 2, Tesla, etc.)
• Maximum power output (kW) per connector
• Operator identity and contact
• Accessibility (24/7? restricted?)
• Authentication and payment methods accepted
• Ad-hoc pricing — the price a non-contract user actually pays

Dynamic (real-time):

• Operational status (available, occupied, out of service, reserved)
• Per-connector status
• Last-update timestamp

The data must be DATEX II. The cadence must be near-real-time. The access must be free. That's the regulation. The implementation is where it gets interesting.

Mobilithek's AFIR Profile (Germany)

Germany was one of the early movers. Mobilithek's AFIR EV-charging profile went live in 2025-08 and has been onboarding CPOs since. It rides on top of the same Mobilithek broker we covered in our mTLS walkthrough — same client-cert auth, same https://mobilithek.info:8443/... URL pattern, distinct Publikations-ID per CPO.

The profile uses DATEX II's EnergyInfrastructure extension. A typical record looks roughly like:

<d2:payloadPublication
    xsi:type="ei:EnergyInfrastructureStatusPublication"
    xmlns:d2="http://datex2.eu/schema/3/common"
    xmlns:ei="http://datex2.eu/schema/3/energyInfrastructure">
  <ei:energyInfrastructureSiteStatus id="DE_CPO_NW_1234">
    <ei:refuelPointStatus id="CP1">
      <ei:status>available</ei:status>
      <ei:lastUpdated>2026-05-01T08:14:05Z</ei:lastUpdated>
    </ei:refuelPointStatus>
    <ei:refuelPointStatus id="CP2">
      <ei:status>occupied</ei:status>
      <ei:lastUpdated>2026-05-01T08:13:50Z</ei:lastUpdated>
    </ei:refuelPointStatus>
  </ei:energyInfrastructureSiteStatus>
</d2:payloadPublication>

Static data ships in a separate EnergyInfrastructureTablePublication. You join the two on energyInfrastructureSiteStatus.id — static once a day, status every 30 to 60 seconds.

Where Member States Diverge

AFIR sets the data model. Each NAP picks the rest:

So even ignoring DATEX-II profile differences, there are at least four distinct authentication flows and three transport variants. And that's just the first seven Member States. Profile detail varies further: some NAPs only expose the dynamic status; some only the static catalogue; the AFIR-mandatory pair is supposed to be both, but enforcement is staged through 2026 and 2027.

The Normalized Model

Inside NAPSPAN, AFIR data lives in our generic features table with feature_type = 'ev_charging'. Type-specific fields go into a JSONB properties column. No new schema for any new country — just a new adapter and a new Register() call.

{
  "id": "de_mobilithek_de_cpo_nw_1234",
  "type": "ev_charging",
  "country": "DE",
  "operator": "EnBW mobility+",
  "name": "EnBW HPC Köln-Nord",
  "latitude": 50.9851,
  "longitude": 6.9550,
  "properties": {
    "connectors": [
      {
        "id": "CP1",
        "standard": "CCS_COMBO_2",
        "max_power_kw": 300,
        "status": "available",
        "last_updated": "2026-05-01T08:14:05Z"
      },
      {
        "id": "CP2",
        "standard": "CCS_COMBO_2",
        "max_power_kw": 300,
        "status": "occupied",
        "last_updated": "2026-05-01T08:13:50Z"
      }
    ],
    "access_24_7": true,
    "payment_methods": ["contactless_card", "ad_hoc_qr", "roaming"],
    "ad_hoc_price_per_kwh_eur": 0.65
  }
}

Connector standards normalize to a fixed enum (CCS_COMBO_2, CHADEMO, TYPE_2, TESLA, NACS, CCS_COMBO_1). Status normalizes to a five-value enum (available, occupied, reserved, out_of_service, unknown). Power normalizes to integer kW. The properties JSONB preserves anything weird the source profile carried so we don't lose information.

Querying Across Borders

The point of the normalization is that one API call gives you charging-point status across every Member State at once.

Available CCS chargers on the Berlin–Amsterdam corridor, ≥ 150 kW:

curl "https://api.napspan.com/api/v1/features/corridor?\
type=ev_charging&\
from_lat=52.52&from_lng=13.40&\
to_lat=52.37&to_lng=4.90&\
buffer_km=15&\
connector=CCS_COMBO_2&\
min_power_kw=150&\
status=available" \
  -H "X-API-Key: your_key"

One call. Two NAPs (Mobilithek + NDW). One consistent response shape. The corridor query uses PostGIS — we buffer the great-circle path by 15 km and intersect with every ev_charging feature whose properties match the filter.

Bounding-box query as GeoJSON, ready for Leaflet:

curl "https://api.napspan.com/api/v1/features/geojson?\
type=ev_charging&\
bbox=2.0,49.5,7.5,51.5" \
  -H "X-API-Key: your_key"

What This Unlocks

Three categories of product get materially better when AFIR data is normalized and queryable continent-wide:

EV routing and trip planning

Today, most EV routing engines fall back on community datasets (OpenChargeMap) or per-network APIs. They miss real-time availability outside the operator's own footprint. AFIR-backed status data fixes both: it's live, and it's continent-wide. Routing engines can prefer chargers that are available right now and have the right connector.

Fleet electrification dashboards

For a logistics operator running mixed-energy fleets across borders, having a single API for charger availability + power + price across every country eliminates a per-network integration matrix. Add SSTP truck-parking (also via NAP) and you get an integrated charge-and-rest planning surface.

Roaming and aggregation platforms

OCPI is the dominant roaming protocol; AFIR is the regulatory disclosure layer. They overlap but aren't identical. AFIR data is the canonical reference for everything a CPO is supposed to disclose; OCPI carries operational and commercial metadata between roaming partners. Aggregators want both. NAPSPAN treats AFIR as the source of truth for static-plus-status disclosure, and exposes operator references so OCPI integrations can join cleanly.

Caveats Worth Knowing

• Coverage is uneven. AFIR rolls in obligations through 2026/2027. Not every CPO publishes yet; not every Member State has its profile finalised. Expect coverage to ramp through the year.
• Pricing is the messy field. "Ad-hoc price" is required, but operators publish it differently — per kWh, per minute, per session, time-of-use tiers. We expose what the source publishes; we don't synthesize it.
• Status freshness varies. Some CPOs push every 30 sec; others every 5 min. We pass through the source's last_updated timestamp on every connector so the consumer can decide how stale is too stale.
• OCPI is still relevant. AFIR is regulatory disclosure; OCPI is operational interconnect. If you're a roaming hub, you still need OCPI integrations — AFIR data complements them, not replaces.

Try It

The API is live with a free tier (no credit card):

• Live map — toggle the EV charging layer
• API docs — full endpoint reference
• Developer portal — sign up and get an API key

If you're building EV routing, fleet electrification, or charging-network analytics on European data, we'd love to hear which countries and which CPO networks matter most to you. AFIR coverage is rolling in over the next 18 months; the order in which we wire CPOs is partly driven by which ones our customers actually use.