General architecture

askacharge.com is a multi-tenant SaaS platform for managing electric vehicle chargers (CSMS — Charging Station Management System). The backend is built on FastAPI (Python, async) with native WebSocket support for OCPP, a PostgreSQL database, and a React frontend. Each brand manages its own charger fleet, tariffs, clients and billing in full isolation, all running on a shared deployment.

Both OCPP 1.6J and OCPP 2.0.1 are supported on the same server, tested with the OCTT (OCPP Compliance Testing Tool) from the Open Charge Alliance. The base URL for the API and WebSocket is:

https://askacharge.com/askacharge

Authentication and roles

Authentication uses JWT (Bearer token), obtained via POST /api/auth/login (OAuth2 password flow: username + password as form-data). The access token expires after 30 minutes; a refresh token (httpOnly cookie) is used to renew it without logging in again.

User layers

REST API by domain

Overview of the main endpoint groups. The full, always current list — 444 operations across 371 routes — is published as OpenAPI 3.1 at /askacharge/openapi.json, with a viewer at /askacharge/docs. Nothing the dashboard does is missing from it: the web interface consumes this very same API.

OCPP integration (chargers)

Connection via WebSocket, one charger per connection. The charge point must be pre-registered under the brand before connecting.

wss://askacharge.com/ocpp/{brand_slug}/{charge_point_id}

Subprotocol negotiated via the Sec-WebSocket-Protocol header: ocpp1.6 or ocpp2.0.1.

Security (Security Profile 2)

Each charger can optionally have a Basic Auth credential associated with it (username = charge_point_id, password generated by the operator from the panel — in the "OCPP Security" section of each charger). When enabled, the WebSocket handshake requires the Authorization: Basic base64(charge_point_id:password) header, and connections without it or with incorrect credentials are rejected. If not enabled, the connection is accepted based solely on the charge_point_id in the URL — we recommend enabling this on every charger exposed to the internet.

Plug & Charge (ISO 15118)

Plug & Charge allows an electric vehicle to authenticate and authorise a charging session automatically when the cable is plugged in — no RFID, app or QR required. The authentication is negotiated between the charger and the vehicle over the power line itself (PLC) using the ISO 15118-2 standard.

It requires chargers with OCPP 2.0.1 and ISO 15118 hardware support. OCPP 1.6J chargers cannot participate in this flow.

Per-brand PKI — own CA

Each brand generates its own EC P-256 Root CA (simplified V2G Root CA, valid for 10 years) from the panel or via API. This CA signs the contract certificates for fleet vehicles, and must be installed on the chargers so they can validate them.

Contract certificates (eMAID)

For each fleet vehicle, a contract certificate is issued linked to its eMAID (Electric Mobility Account ID, format ES-ACH-XXXXXXXXXX-C). The vehicle stores it and presents it to the charger at each session. askacharge.com delivers it automatically via Get15118EVCertificate OCPP when the charger requests it.

OCPP 2.0.1 flow

When a compatible vehicle is plugged in, the charger opens an ISO 15118 session and sends an Authorize message with id_token.type = "ISO15118" and the iso15118CertificateHashData field. askacharge.com verifies the eMAID against the active contract table and validates the certificate hash to prevent impersonation. If the vehicle does not yet have the certificate downloaded, the charger requests Get15118EVCertificate and askacharge.com responds with the certificate chain (contract + CA) in EXI/DER format.

General market vehicles (non-fleet)

Consumer vehicles (IONIQ 6, BMW iX, etc.) come from the factory with a contract certificate signed by a root CA recognised by the manufacturers — primarily Hubject eMobility PKI in Europe. To authorise those drivers, askacharge.com would need to connect to that external PKI, which requires a contract with Hubject and is on the roadmap but not yet active.

Today, Plug & Charge on askacharge.com works for own fleet: vehicles whose eMAIDs you have issued as the operator. For all other drivers, combining with RFID, QR payment or the driver portal is recommended.

Smart Charging & Energy

askacharge.com manages charging power dynamically across three independent levels that can be combined: power distribution by location, conditional rules based on solar output or energy price, and OCPP charging profiles per charger. Everything is applied in real time without operator intervention.

Power distribution by location (SPL / load balancing)

Each location can have a maximum power limit (kW). askacharge.com distributes that ceiling across active chargers by sending SetChargingProfile (OCPP 1.6J and 2.0.1) automatically when a session starts or stops. Available strategies: even (equal for all) and priority (per-charger priority). This allows chargers to be installed without upgrading the electrical supply connection.

Solar integration

The operator configures their photovoltaic installation (peak power, optional battery, minimum surplus to trigger charging) and publishes real-time readings from their inverter or meter. askacharge.com calculates the available surplus and feeds it into the rules engine.

Charging rules engine

The operator defines prioritised rules that are evaluated every 5 minutes against the current state (solar surplus, time of day, energy price). The first rule whose condition is met applies its action via ChangeConfiguration OCPP to all active chargers on the brand.

POST /api/brand/solar/rules
{
  "name": "Solar surplus only",
  "priority": 10,
  "condition_type": "surplus_min",
  "condition_value": { "watts": 1500 },
  "action": "charge_solar_only"
}

Dynamic energy tariffs

The rules engine can operate with three grid price sources:

• PVPC — hourly prices from REE ESIOS, updated automatically every hour. Available at GET /api/brand/pvpc/today.
• OMIE — day-ahead wholesale market (spot) price, with a configurable margin per brand.
• Fixed tariff — a constant price set by the operator.

The pvpc_max condition in charging rules makes it straightforward to charge only when energy costs less than €0.10/kWh and pause during peak hours — with no manual intervention at all.

Analytics and reporting

The platform provides real-time dashboards, historical analytics with period comparison, monthly financial forecasting, per-charger performance rankings, exportable ESG reports in PDF, and automatic AI-based anomaly detection. All data is accessible via API for integration with external BI tools.

Operational dashboard

Advanced analytics

ESG report (PDF)

GET /api/brand/esg-report generates a downloadable PDF with the environmental impact of the period: kWh delivered, CO₂ avoided (factor 130 g/kWh vs combustion), equivalent trees planted, and a breakdown by fleet client. Ready for inclusion in corporate sustainability reports or CSRD disclosures.

Anomaly detection (AI)

A detection engine runs four independent analysers every 30 minutes across all recent transactions. Alerts are stored in the anomaly_alerts table with severity and description, and the operator is notified by email.

AskaCharge Hub / OCPI roaming

The AskaCharge Hub is an internal roaming network between brands/operators sharing the platform: a single OCPI integration gives access to all chargers in the network, with no need for individual bilateral agreements. Towards external partners (Hubject, GIREVE, ocpi.io...), the Hub presents itself as a single OCPI 2.2 party: ES*ACH.

https://askacharge.com/askacharge/ocpi/hub/versions

Commission model: 1% per cross-brand session, settled on the 1st of each month. The eMSP charges the driver using their saved card and askacharge.com transfers to the CPO — with no payment risk between brands, since both billing accounts are on the same platform. External membership requests: POST /api/public/hub/apply, see also the Hub page.

Spanish tax invoicing

askacharge.com generates and submits invoices to Spanish tax systems automatically, with no additional configuration required from the operator beyond entering their tax details during onboarding. The platform detects the brand's territory and applies the corresponding system.

Verifactu — common territory (AEAT)

Each completed transaction generates an invoice record in Verifactu format (Royal Decree 1007/2023): XML signed with the chained SHA-256 hash chain, a validation QR code, and automatic submission to the AEAT SOAP web service. Records are stored with the tax authority's response status (aeat_ok, error code, timestamp). Rejected invoices enter an automatic retry queue.

TicketBAI — foral territories

For operators in Bizkaia, Gipuzkoa or Araba, the platform issues TicketBAI invoices with XAdES-EPES signature using the brand's digital certificate. They are submitted to the correct endpoint for each foral treasury. Bizkaia also supports monthly aggregated submission via LROE (Lote de Registros de Operaciones Económicas). The TicketBAI QR is included in the invoice PDF.

What gets invoiced

ERP integration

Issued invoices can optionally be synchronised with Holded via API (PUT /api/brand/erp/config). The operator provides their Holded API key and the platform sends each invoice at the moment of generation.

Security

The platform implements layered security: robust authentication with token rotation, software-based 2FA, OCPP protocol-level security, signing of outbound events, and GDPR privacy controls.

Authentication — JWT + rotating refresh token

The JWT access token has a 30-minute lifetime. The refresh token is issued as an httpOnly; SameSite=Lax; Secure cookie (never accessible from JavaScript) and is rotated on every use: when the access token is renewed, the previous refresh token is invalidated and a new one is issued. If an already-used token is presented again, the platform detects a potential session theft and immediately revokes all refresh tokens for that user. The main app cookies (/app) and driver portal cookies (/portal) are independent to prevent privilege escalation between layers.

2FA — TOTP (RFC 6238)

brand_admin users can enable two-factor authentication with any compatible app (Google Authenticator, Aegis, 1Password…). The flow: setup → provisioning URI + QR → first code verification → activation with delivery of 8 single-use backup codes (SHA-256 in the database, plaintext shown once). 2FA is required at login if enabled.

OCPP Security Profile 2 — Basic Auth per charger

Each charger can have an independent credential: username = charge_point_id, password generated and rotatable from the panel (SHA-256 hash stored, plaintext shown once). When enabled, the WebSocket handshake requires the Authorization: Basic … header and rejects connections without it. The endpoint POST /api/brand/chargers/{id}/rotate-password allows rotating the credential without touching the configuration of the rest of the fleet.

API keys — SHA-256 hash, scopes

API keys are stored exclusively as SHA-256 hashes — the plaintext value is only shown at creation time and can never be retrieved. Each key carries a set of read and write scopes that bound what it can do, and every write is recorded: see the API keys section.

Webhooks — HMAC-SHA256 signature

Each outbound event includes the header X-AskaCharge-Signature: sha256=<hex>, computed using the endpoint's own secret (unique per endpoint, never shared). The receiver can verify the authenticity of the event before processing it.

Privacy and GDPR

For each fleet client the operator can execute:

V2G and energy aggregation

Vehicle-to-Grid (V2G) allows electric vehicles to return energy to the grid during periods of high demand or elevated prices, turning them into manageable distributed batteries. askacharge.com is designed to operate as a V2G aggregation platform as soon as the hardware allows — the standards, protocols and dispatch logic are already built into the architecture.

Implemented standards

Dispatch engine — already operational

The Smart Charging rules engine (see previous section) is designed for bidirectional dispatch: the pvpc_max and time_range conditions already allow defining discharge windows ("discharge when PVPC > €0.18/kWh"), and the charge_watts action with a negative value will be mapped to an OCPP discharge profile when the charger supports it. PVPC and OMIE spot prices are updated hourly from REE ESIOS — the price signal for dispatch is already available in real time.

Aggregator role (RD 88/2026 — SRAD)

The Spanish regulatory framework (Royal Decree 88/2026) establishes the role of the Active Demand Response System (SRAD): an aggregator that pools distributed flexibility capacity (EV batteries, solar, heat pumps) and offers it to Red Eléctrica as a balancing service. askacharge.com is positioned to operate as a SRAD as soon as:

• The minimum regulatory threshold is reached (1 MW of aggregated manageable capacity)
• Certified bidirectional hardware is available in the fleet
• Registration as an independent aggregator with CNMC/REE is completed (a role enabled by RD 88/2026, with no requirement to be an electricity supplier)

The platform already aggregates real-time power metrics by location (location_limits), knows the status of every charger and active session, and has the OCPP channel to modify charging profiles within seconds — the three key ingredients of demand response dispatch.

askacharge.com as an independent aggregator (RD 88/2026)

Royal Decree 88/2026 creates in Spain the role of the independent aggregator: an entity that pools distributed flexibility capacity (EV batteries, solar, heat pumps) and offers it to Red Eléctrica in balancing and adjustment service markets, without needing to be a licensed electricity supplier.

askacharge.com is positioned to register as an independent aggregator with a unique structural advantage: it already controls in real time the chargers of all brands in the network. Every operator that joins contributes their installed capacity to the aggregated pool. The regulatory threshold is 1 MW — achievable by aggregating several network brands before any individual operator could reach it alone.

For askacharge.com's operator clients, joining the aggregation pool means a new passive revenue stream: their chargers keep working normally, and when REE activates a curtailment signal (load reduction), askacharge.com handles the dispatch automatically and transfers their share of the compensation.

V2G: grid injection and dynamic price arbitrage

With bidirectional hardware, a fleet of parked EVs can return energy to the grid during peak demand — an additional service that REE remunerates above availability. Combined with price arbitrage, the EV becomes a financial asset for the operator:

Important: with Spain's high solar penetration, the traditional "cheap at night / expensive during the day" model no longer holds. PVPC prices can hit historical lows at midday due to photovoltaic overproduction (values below €0.02/kWh are common), while the real price peak occurs in the late afternoon and evening (19–22h), when the sun drops but demand remains high. The optimal arbitrage window is solar midday trough → late afternoon peak, with spreads that can exceed a 15× factor.

askacharge.com handles this natively: PVPC and OMIE spot prices are updated hourly from REE ESIOS and are already available in real time on each operator's dashboard. The pvpc_max condition in the rules engine evaluates the current price at every charging decision — without assuming fixed time patterns, adapting automatically to solar seasonality.

Driver app (marketplace)

askacharge.com includes a three-layer driver experience with no native app required: a publicly accessible map, a registration-free QR charging flow, and a full driver portal installable as a PWA.

Public map — charging marketplace

Available at /mapa without login. Shows askacharge.com chargers and the national REVE/REE network in real time. Clicking on an askacharge.com charger opens a modal with:

• Per-connector status (up to 4), with visual selector and real-time colour indicator
• Operator's public tariff with estimated cost per hour
• QR generated client-side for the selected connector
• "Start charging" button linking directly to the payment flow

QR charging — no account, no app

The driver scans the physical QR on the charger or the one from the map. The full flow:

1. Charger info: name, status, tariff and cost estimate
2. Stripe €50 pre-authorisation (Apple Pay / Google Pay / card) — manual capture of the exact amount
3. Live active session: elapsed time, kWh charged, accumulated cost
4. Final summary with receipt and CO₂ saved

Compatible with all tariff modes: per kWh, per hour, per session, combined, dynamic PVPC and free. The cost estimate is displayed before confirming payment.

Driver portal — installable PWA

Each operator can offer a driver portal at /portal/{slug}/, installable as a PWA on iOS and Android (without going through the App Store). It includes:

Outbound webhooks

Each brand can register custom HTTP endpoints to receive real-time events (HMAC-signed, unique secret per endpoint) from /api/brand/webhooks. Events include: session.stopped (among others), with energy, amount, CO₂ saved and stop reason.

API keys — the credential for an agent or an integration

An alternative to JWT for server-to-server integrations and for AI agents. Managed from /api/brand/api-keys, stored as SHA-256 hashes, with the plaintext value shown only once at creation. Sent in X-Api-Key or as Authorization: Bearer.

An API key reaches whatever the brand's human administrator reaches, bounded by the scopes that brand granted it. That is deliberate: the platform offers every option and the operator decides which ones to hand to its agent. Start read-only and widen later, or grant full access from the start.

The required scope is derived from the resource and the method: GET needs :read, everything else :write. Write includes read. The wildcards * and family:* are accepted.

The live catalogue is returned by GET /api/brand/api-keys/scopes, so an agent can find out which permissions exist before asking for them.

How much an API key reaches

Of the 444 operations in the API, 228 are within reach of an API key and 210 sit outside its perimeter by design: the driver portal (52), platform superadmin (37), the OCPI roaming endpoints (37+10), the public QR payment ones (18), authentication (16) and internal invoicing (15). That half is not a gap: they are operations a brand's agent has no business touching.

These figures come from counting the published OpenAPI against the permission table, not from an estimate. You can reproduce them from openapi.json.

Narrowing a key to specific locations

In chargers and commands, a scope accepts a location suffix: commands:write@hotel-madrid. An installer running several sites under one brand can give an agent permission to reset the chargers in Madrid but not the ones in Barcelona. The suffix can be repeated for several locations on the same key.

The location is the charger's location_name, compared as a slug (Parking Norte and parking-norte are the same one). Your brand's actual locations are returned by GET /api/brand/api-keys/scopes, and appear as buttons in the dashboard when choosing permissions.

It narrows which chargers the key can act on, not what it can read. A command or a creation outside its locations returns 403 naming the ones it is allowed; a write that names neither charge_point_id nor location_name is refused too, because there is no way to tell where it lands. But listings and the dashboard still return the whole brand: filtering reads as well would mean trimming the body of dozens of different responses, and we would rather not half-promise something the trust in a permission depends on.

In the other families the suffix is rejected when the key is created: a tariff or an invoice does not belong to a location. And a key without a suffix still reaches the whole brand — the widest permission granted always wins.

Retries without duplicates

Every write accepts the Idempotency-Key header. If the request is repeated with the same key, the first response is returned along with Idempotent-Replay: true instead of running it again. Reusing the key with a different body returns 422, and retrying while the first call is still in flight returns 409. An agent retries by design, and this keeps a dropped connection from duplicating a charger, a client or a charge.

MCP server

An agent can connect over Model Context Protocol to https://askacharge.com/askacharge/api/mcp, authenticating with the same API key (Authorization: Bearer ask_live_… or X-Api-Key). Nothing to install: it is plain HTTP, JSON-RPC 2.0 over POST.

It returns the tools already described — what each one does and when to use it — and only the ones that key can run: if the brand did not grant commands:write, the start, stop and reset tools do not even appear in the list. For anything without its own tool there is askacharge_llamar_api, which opens all 444 operations under the same permission checks. The filter is by family and action: a key narrowed to locations does see those tools, and gets the 403 when it runs one against a charger in another location.

The protocol handshake — initialize, ping and tools/list — is answered without an API key, because that is what MCP directories and clients ask for before they have credentials; with no key you get the full catalogue of 21 tools, which is public anyway. Running any of them does require the key, and from there everything above applies again.

The MCP server is not a side door: every tool runs against this same REST API, so it goes through the same scopes, the same activity trail and the same rate limit.

Activity trail

Every write and every rejected attempt is recorded: which key, which operation, the result, the source IP and how long it took. Available in the dashboard under API keys → Activity, or over the API with GET /api/brand/api-keys/audit (scope keys:read). Kept for 90 days. Successful reads are not recorded — an agent makes hundreds and they would bury what matters. An attempt with a key that does not exist is logged too.

Usage limit

300 requests per minute per key. Beyond that the API answers 429 with Retry-After.

Where an API key does NOT reach

Not even with the * wildcard: /api/auth (identity and passwords), /api/admin (platform superadmin), the driver portal and the OCPI endpoints. Those answer 401. A key always belongs to one brand and cannot step outside it.

Simplified endpoints

Besides the full API, two convenience endpoints with a stable shape, meant for integrations that only need to pull data:

Related links