Technology / proposed architecture

Connect through interfaces. Keep the infrastructure.

A unified access and interoperability layer designed around charger identification, authorization, session orchestration and payment workflows — subject to partner capabilities and agreement.

Discuss API Integration

The intended platform

One layer. Participating systems.

Proposed platform architecture

EVMavrik Backend

Proposed orchestration of partner authorization, sessions and records. Existing website backend stores partnership enquiries only; no charging backend is connected.

DATA EXCHANGE / SUBJECT TO INTEGRATION

  • Charger and location information
  • Availability and tariff data
  • Authorization requests and responses
  • Session updates and charging records
  • Payment status and reconciliation, where supported

Your management system stays yours.

OCPI supports interoperability and roaming exchanges between participating parties. OCPP connects compatible stations with their charging-management systems; EVMavrik does not replace that backend. Neither protocol automatically grants access to an operator’s network.

Partner APIs are used according to documented capabilities, authentication requirements and agreed access policies.

QR + API demonstration

Inspect the experience, not a production connection.

Choose a sample operator and charger, then follow a local identification and authorization simulation.

Interactive Demo — Simulated DataNO LIVE API CALLS
EVMavrik demonstration identifier QR

Sample charger A01

CCS2 · 60 kW

₹18/kWh · sample tariff

evmavrik-demo:sample-a:DEMO-A01

This genuine QR contains a demo-only identifier, not a production URL or credential. Identification and authorization below run locally; no camera, payment or charger connection is used.

  1. 01 / QR identifier
  2. 02 / Resolve charger
  3. 03 / Authorize

Ready to inspect a demo QR

{
  "request": {
    "operation": "demo.resolve",
    "identifier": "evmavrik-demo:sample-a:DEMO-A01"
  },
  "response": {
    "simulated": true,
    "operator": "Sample Operator A",
    "charger_id": "DEMO-A01",
    "connector": "CCS2",
    "power_kw": 60,
    "status": "AWAITING_DEMO_SCAN"
  }
}

No vehicle is charging. No payment is processed. Operator availability and authorization are simulated.

Integration documentation preview

A shared language for technical conversations.

Illustrative API Example — Not a Live Production Endpoint

GET /illustrative/v1/chargers

List sample stations and operator information.

Parameters, status and possible errors

Status: local simulation only. No parameters required. POST examples include a sample connector and session ID where applicable. Possible responses: 404 unknown identifier, 403 authorization denied, 422 unsupported operation, 503 partner unavailable. No production credentials or partner endpoints are configured.

Example request

{}

Example response

{
  "simulated": true,
  "chargers": [
    {
      "id": "DEMO-A01",
      "name": "Sample charger A01",
      "location": "Sample location A",
      "connectors": [
        "CCS2"
      ],
      "power": 60,
      "tariff": 18,
      "availability": "SIMULATED_AVAILABLE",
      "operatorId": "sample-a",
      "operatorName": "Sample Operator A",
      "identifier": "evmavrik-demo:sample-a:DEMO-A01",
      "stationName": "Sample charger A01",
      "dataMode": "DEMO",
      "lastUpdated": "2026-10-24T00:00:00Z",
      "access": "Public access in simulation only",
      "connectorDetails": [
        {
          "id": "DEMO-A01-1",
          "type": "CCS2",
          "powerKw": 60,
          "tariffInr": 18,
          "status": "DEMO"
        }
      ]
    },
    {
      "id": "DEMO-A02",
      "name": "Sample charger A02",
      "location": "Sample location A",
      "connectors": [
        "Type 2"
      ],
      "power": 22,
      "tariff": 16,
      "availability": "SIMULATED_IN_USE",
      "operatorId": "sample-a",
      "operatorName": "Sample Operator A",
      "identifier": "evmavrik-demo:sample-a:DEMO-A02",
      "stationName": "Sample charger A02",
      "dataMode": "DEMO",
      "lastUpdated": "2026-10-24T00:00:00Z",
      "access": "Public access in simulation only",
      "connectorDetails": [
        {
          "id": "DEMO-A02-1",
          "type": "Type 2",
          "powerKw": 22,
          "tariffInr": 16,
          "status": "DEMO"
        }
      ]
    },
    {
      "id": "DEMO-B01",
      "name": "Sample charger B01",
      "location": "Sample location B",
      "connectors": [
        "CCS2"
      ],
      "power": 30,
      "tariff": 20,
      "availability": "SIMULATED_AVAILABLE",
      "operatorId": "sample-b",
      "operatorName": "Sample Operator B",
      "identifier": "evmavrik-demo:sample-b:DEMO-B01",
      "stationName": "Sample charger B01",
      "dataMode": "DEMO",
      "lastUpdated": "2026-10-24T00:00:00Z",
      "access": "Public access in simulation only",
      "connectorDetails": [
        {
          "id": "DEMO-B01-1",
          "type": "CCS2",
          "powerKw": 30,
          "tariffInr": 20,
          "status": "DEMO"
        }
      ]
    }
  ]
}

Partner-dependent scope

Proposed integration capabilities.

Proposed integration capabilities
  • 01Charger and location discovery
  • 02Connector information and availability
  • 03Tariff retrieval
  • 04QR-based charger identification
  • 05Driver authentication and authorization
  • 06Remote start and stop, where supported
  • 07Session status and monitoring
  • 08Charging detail records (CDRs)
  • 09Payment workflow coordination
  • 10Session reconciliation
  • 11Error handling and integration monitoring

Illustrative transaction flow

From QR identification to charging records.

Actual flow depends on partner architecture, authorization rules and payment integration. None of these steps performs a live transaction here.

  1. 01

    SCAN

    Driver scans the charging QR.

  2. 02

    IDENTIFY

    EVMavrik identifies the participating charging point.

  3. 03

    SELECT

    Driver selects the relevant connector/session option.

  4. 04

    PAY

    Applicable payment requirements are coordinated where supported.

  5. 05

    AUTHORIZE

    Authentication and access authorization follow partner rules.

  6. 06

    START

    A session may be initiated where partner APIs support it.

  7. 07

    MONITOR

    Charging/session information is tracked.

  8. 08

    COMPLETE

    Charging session ends.

  9. 09

    CALCULATE

    Final transaction amount is determined.

  10. 10

    RECEIPT

    Available session information or a receipt may be provided.

  11. 11

    SETTLEMENT

    Partner-side settlement and reconciliation processes handle the commercial transaction.

Responsible interoperability

Trust is part of the integration.

Intended engineering and operating principles — not claims of certification or a completed production audit.

  • Server-side partner secret management and least-privilege access
  • Authentication and authorization for protected APIs
  • HTTPS for production traffic and appropriate partner-data validation
  • Data minimization; logging and monitoring where implemented
  • Agreed operational responsibilities and approval before production

Payment services and compliance arrangements depend on the chosen provider and operating model. No payment-provider approval or security certification is claimed.

Let’s connect the ecosystem

Your infrastructure.
A simpler connected experience.

One QR. Every EV. One seamless charge.

Partner With EVMavrik