EV充電API統合が重要な理由
ほとんどのEV充電ソフトウェアのページでは、機能について説明されています。ダッシュボード、請求、支払い、充電器の監視、ユーザー管理、レポート機能などが挙げられています。これらはすべて重要ですが、必ずしも購入を決める決め手になるとは限りません。
多くの事業者が本当に知りたいのは、もっとシンプルな疑問だ。このプラットフォームは、私たちが既に使っているシステムと接続できるのか?
ホテルの場合、EV充電プラットフォームは、宿泊客のアカウント、客室料金請求、駐車券の認証と連携する必要があるかもしれません。ショッピングモールの場合、駐車場のアクセス管理、ロイヤルティキャンペーン、テナントの収益レポートと連携する必要があるかもしれません。不動産管理会社の場合、居住者のアカウント、月次明細書、アクセス制御と連携する必要があるかもしれません。車両運行会社の場合、車両、ドライバー、営業所、コストセンター、運行スケジュールと連携する必要があるかもしれません。
言い換えれば、CPMSは孤立した存在であることは稀である。 充電ポイント管理システム より大きなビジネスワークフローの中に組み込まれる必要があります。そこでEV充電APIの統合が重要になってきます。
APIは単なる技術的なチェックボックスではありません。課金データが、毎週誰かが手動でスプレッドシートをエクスポートすることなく、決済ゲートウェイ、請求システム、ERPプラットフォーム、駐車場管理ソフトウェア、車両管理ツール、CRM、作業指示システム、財務ダッシュボードなどに取り込まれるかどうかを決定するものです。
優れたAPI統合により、課金ソフトウェアはスタンドアロンのプラットフォームから、通信事業者の日常業務プロセスの一部へと変化する。
EV充電APIとは何ですか?
EV充電APIとは、他のシステムがEV充電プラットフォーム内のデータを読み取ったり、書き込んだり、データに基づいて反応したりできるようにする構造化されたインターフェースです。実際には、CPMS(充電プラットフォーム管理システム)が外部ソフトウェアと情報を交換できるようにします。
その情報には、充電ステーション、コネクタの状態、ユーザーアカウント、RFIDカード、充電セッション、料金プラン、支払い記録、請求書、障害アラーム、エネルギー消費量、決済レポート、車両充電状況などが含まれる場合があります。
強力なAPIは、次のような質問に答えることができます。
- 現在、どの充電器がオンラインですか?
- この充電セッションを開始したのはどのユーザーですか?
- そのセッションではどれくらいのエネルギーが消費されましたか?
- どのような関税率が適用されましたか?
- 支払いは完了しましたか?
- この請求費用はどのコストセンターが負担すべきでしょうか?
- 充電開始時に駐車場のゲートを開けるべきでしょうか?
- 充電器がオフラインになった場合、作業指示書を作成する必要があるでしょうか?
これはOCPPとは異なります。OCPPは主に充電器とバックエンドプラットフォーム間で使用されます。 オープンチャージアライアンス OCPPは、充電ステーションと充電管理システム間のオープンな通信プロトコルとして定義されています。一方、EV充電APIは通常、充電ネットワーク外のビジネスシステムとCPMSを接続するために使用されます。
また、OCPIとも異なります。OCPIは主にCPOとeMSP間のローミングと相互運用性に使用されます。 OCPI仕様リポジトリ これは、充電ポイント事業者とeモビリティサービスプロバイダー間の拡張可能なローミングのためのプロトコルとして説明されています。API統合はより広範で、充電業務とビジネス運営を支える商用システムを接続します。
API統合が解決する真のビジネス課題
充電セッションではデータが生成されます。しかも、かなりの量です。
各セッションには、ドライバー、車両、充電ポイント、コネクタ、料金プラン、エネルギー量、支払い記録、請求書、駐車イベント、割引ルール、コストセンター、サービスアラートなどが含まれる可能性があります。CPMSがこれらのデータを独自のプラットフォーム内に保持している場合、オペレーターは最終的に手動でデータを移動する必要があります。
手作業は問題を引き起こします。財務チームは不足しているレポートを探し出し、現場管理者は利用状況の数値を求め、車両管理者はドライバーごとの充電コストを知りたがり、駐車場管理チームは充電状況に合わせたアクセスルールを求め、ドライバーからの苦情があった際にはカスタマーサポートがセッション履歴を必要とし、充電器が何時間もオフラインになる前にメンテナンスチームがアラートを受け取る必要があります。
だからこそ、API連携は「あれば便利」な機能ではないのです。デモで見栄えの良いソフトウェアと、実際に充電ビジネスを運営できるソフトウェアとの違いは、まさにそこにあるのです。
評価する事業者向け EV充電バックエンドソフトウェアAPI対応状況は、購入検討の初期段階から議論に含めるべきです。
支払いと請求の統合
ほとんどの事業者が最初に注目するAPIのユースケースは、決済と請求です。
充電セッションは、ドライバーがケーブルを抜いた時点で終了するわけではありません。セッションは引き続き料金計算、請求、支払い、記録、照合、そして場合によっては複数の関係者間での分配が必要となります。決済統合により、CPMSはカード処理業者、ローカルウォレット、プリペイドアカウント、請求書発行システム、払い戻しワークフロー、収益分配ルールなどと連携できます。
小規模な充電ステーションであれば、これはシンプルに見えるかもしれません。ドライバーはQRコードまたはカードで支払い、運営者はそのお金を受け取ります。しかし、事業が拡大するにつれて、支払いの流れはより複雑になります。1回の充電セッションで、割引、待機料金、駐車料金、月額請求、法人アカウント、VAT請求書、複数加盟店の決済、または地主への収益分配などに対応する必要が生じる可能性があります。
ここでAPIが重要になります。CPMSは、課金セッションデータを決済システムまたは請求システムに自動的に送信できる必要があります。また、支払い状況の更新、返金確認、および決済結果を受信できる必要もあります。
成熟した課金システムでは、決済統合には通常、いくつかの種類のイベントが必要です。
- セッションが開始されました
- セッション終了
- 支払いが承認されました
- 支払いが失敗しました
- 請求書が作成されました
- 返金処理済み
- 決済完了
これが、Webhook が重要な理由です。決済システムでは、Webhook はイベントが発生したときに別のシステムに通知するためによく使用されます。たとえば、 StripeのWebhookに関するドキュメント この図は、支払いイベントを外部システムに自動的に送信する方法を示しています。EV充電プラットフォームも同様のイベント駆動型の考え方が必要です。なぜなら、充電は静的な取引ではなく、セッションベースのビジネスだからです。
オペレーターがこのワークフローを拡張したい場合は、API統合を一緒に計画する必要があります。 EV充電決済ソリューション そして EV充電料金請求ソフトウェア.
駐車場とアクセス制御の統合
駐車場との連携は、EV充電ソフトウェアにおいて最も過小評価されている要素の一つである。
多くの商業施設では、駐車料金の支払いは駐車場とは切り離されていません。ホテル駐車場、アパートのガレージ、オフィスビル、商業施設、空港、管理駐車場などで同様の状況が見られます。運転者の料金支払い権限は、駐車状況、ナンバープレート認識、訪問者ステータス、客室予約、居住者アカウント、テナントアクセスレベルなどによって異なる場合があります。
駐車場との連携により、利用体験は格段にスムーズになります。例えば、ドライバーはナンバープレート認識機能を使って駐車場に入り、EV充電スペースに駐車し、アプリやRFIDカードで充電を開始し、駐車と充電の記録をまとめて受け取ることができます。また、居住者は指定されたスペースでのみ充電が許可され、訪問者は即座に料金を支払う必要があるといったケースも考えられます。
API連携がない場合、駐車システムと充電システムはしばしば別々の記録として扱われます。これはドライバーにとって混乱を招き、事業者にとっては事務作業の増加につながります。
優れたCPMS APIは、駐車利用者ID、ナンバープレート、駐車セッションID、充電器ID、充電状況、駐車料金、課金料金、アクセス許可などのデータを交換できる必要があります。より高度なプロジェクトでは、ゲートアクセスをトリガーしたり、駐車割引を検証したり、課金アクティビティを駐車場プラットフォームに送信したりすることも可能です。
これは、特にアパートや共同住宅の充電プロジェクトにおいて役立ちます。これらのプロジェクトでは、充電サービスを既存の不動産管理およびアクセス制御のワークフローに適合させる必要があるからです。
ERPと財務の統合
EV充電が利便性の高いサービスから、管理された事業部門へと移行する際には、ERPシステムとの統合が重要になる。
財務チームは、独立したダッシュボードを新たに作成することを望んでいません。彼らが求めているのは、売上、税金、払い戻し、売掛金、コストセンター、決済記録といった情報が、会社が既に資金を管理している場所に表示されることです。
企業運営者にとって、CPMSは取引データをERP、会計システム、または財務システムに送信する必要がある場合があります。これには、日々の収益概要、月次請求書、顧客口座残高、税務情報、エネルギーコスト、サイトレベルの利益レポート、およびパートナー決済データなどが含まれます。
目標は自動化だけではありません。目標は信頼を築くことです。経理チームが請求注文と支払記録、決済報告書を照合できるようになれば、請求業務の管理が容易になります。
ここでも、課金ロジックが非常に重要になります。課金は必ずしも単純なkWhベースの取引ではありません。最終的な料金には、エネルギー価格、時間料金、待機料金、駐車料金、セッション料金、割引、VAT、サイト所有者の取り分、プラットフォーム手数料などが含まれる場合があります。
CPMSがAPIを通じてクリーンな請求データを公開できない場合、ERPとの連携は困難になります。結果として、オペレーターはCSVファイルをエクスポートし、データを手動でクリーンアップし、収益を手作業で確認する必要が生じる可能性があります。
そのワークフローは拡張性に欠ける。
CRMと顧客アカウントの統合
課金データは、CRMシステムにとっても有用です。
多くの事業者にとって、課金対象となるユーザーは単なる匿名取引ではありません。ホテル宿泊客、居住者、企業従業員、車両運転手、テナント、VIP会員、定期購読者など、様々な立場の人々が存在します。ユーザーグループごとに、料金体系、アクセス権限、支払い方法、サービスに対する期待値が異なる場合があります。
CRM連携により、事業者は充電行動と顧客関係を結びつけることができます。ホテルで頻繁に充電するユーザーにはロイヤルティ特典を提供したり、法人顧客には月次レポートを提供したり、居住者には物件アカウントに充電料金が加算された情報を提供したり、フリート顧客は車両レベルおよびドライバーレベルのコスト分析を必要としたりすることができます。
CPMS APIは、顧客データとアカウントデータをシステム間で安全にやり取りできるようにする必要があります。最低限、これにはユーザーID、アカウントの種類、RFIDまたはアプリの識別情報、請求履歴、請求書のステータス、サポート記録などが含まれるべきです。
規模の大きな事業者にとって、CRM統合はセグメンテーションにも役立ちます。すべてのドライバーを同じように扱うのではなく、顧客タイプに基づいて価格設定、アクセス、コミュニケーションに関するルールを作成できます。
車両充電API統合
車両充電は、API統合を重視する最も強力な理由の一つです。
車両管理者は、充電ステーションのことだけを考えているわけではありません。車両、ドライバー、ルート、車庫、スケジュール、稼働時間、走行距離あたりのコストなど、あらゆる要素を考慮します。彼らにとって、充電データは車両運用の他の部分と連携していなければなりません。
車両充電APIは、CPMSを車両管理システム、ルート計画ツール、テレマティクスプラットフォーム、デポスケジューリングソフトウェア、および企業財務システムと接続することができます。
最も有用なデータポイントには、多くの場合、以下が含まれます。
- 車両識別番号
- ドライバーID
- 配送センターの場所
- 充電セッションの開始時刻と終了時刻
- 消費エネルギー
- 充電状態(利用可能な場合)
- 充電コスト
- コストセンター
- 料金例外または障害記録
小規模な車両群であれば、最初は手作業で対応できるかもしれません。しかし、数十台、数百台もの車両が関係するようになると、手作業による報告はボトルネックとなります。
車両運行管理者は、車両が次の運行ルートに出発できる状態にあるか、どの充電器が十分に活用されていないか、どの車庫に容量の増強が必要か、そして充電コストをどのように配分すべきかを知りたいと考えています。そのためには、充電器の状態画面だけでなく、データの統合が不可欠です。
API統合は、より良い計画にも役立ちます。充電アクティビティは、負荷管理、デポスケジューリング、エネルギーレポートに反映できます。オペレーターがスマート充電も検討している場合は、どのように EV充電負荷分散ソフトウェア 車両群およびサイトレベルのエネルギー制約に対応できます。
作業指示とメンテナンスの統合
充電器の稼働時間は、ユーザーエクスペリエンスにおいて最も目に見える要素の一つです。決済フローが完璧であっても、充電器がオフラインであれば、ドライバーはダッシュボードの表示がどれほど優れていても気にしません。
だからこそ、作業指示と保守管理の統合は非常に価値があるのです。
CPMSは、充電器がオフラインになったとき、コネクタが障害を報告したとき、充電が繰り返し失敗したとき、またはサイトに異常な動作が見られたときを既に把握しています。問題は、その情報をCPMS内に留めておくか、チームの保守プロセスに取り込むかということです。
API連携により、障害発生時に作業指示システムにチケットを自動的に作成できます。重大なアラートはSlack、SMS、WhatsApp、またはメールで送信できます。繰り返し発生する障害はエスカレーションできます。技術者が修理依頼を完了すると、そのステータスが課金プラットフォームに送信されます。
多くの業務において、自動化によって実際にコスト削減が実現します。その価値はAPIそのものではなく、アラームの見落としの減少、ダウンタイムの短縮、SLAの追跡精度の向上、そして手作業による調整の削減にあります。
ワークフロー自動化ツールなど n8n チームがさまざまなシステムを連携させ、イベントベースのタスクを自動化する方法を示します。電気自動車の充電においても同様の考え方が当てはまります。充電データが利用可能になれば、日常的な運用タスクを手動での確認作業ではなく、ワークフローとして自動化できます。
優れたCPMS APIには何が含まれるべきか
購入者は、優れたAPIに関する質問をするために開発者である必要はありません。実際、最も重要なAPIに関する質問の中には、ビジネス上の質問も含まれています。
優れたCPMS APIは、通常、充電器データ、コネクタの状態、充電セッション、ユーザー、トークン、料金プラン、支払い、請求書、アラート、レポートへのアクセスをサポートする必要があります。また、安全な認証、ロールベースの権限設定、イベント通知、ドキュメント、サンドボックステスト、バージョン管理もサポートする必要があります。
APIは、技術チームが開発に利用できるほど明確であると同時に、ビジネスチームが信頼できるほど構造化されている必要がある。
EV充電APIを評価する際、購入者は以下の点を問うべきである。
- このプラットフォームはREST APIやその他の統合方法を提供していますか?
- リアルタイムのWebhookに対応していますか?
- 課金セッション、支払い記録、請求書を取得できますか?
- 充電器の状態や故障アラームにアクセスできますか?
- ユーザー、RFIDカード、または認証トークンを管理できますか?
- 駐車場管理システム、ERPシステム、CRMシステム、または車両管理システムとの連携に対応していますか?
- サンドボックス環境はありますか?
- APIの権限は、役割別またはアカウント別に分けられていますか?
- バージョン管理に関するポリシーはありますか?
- ログや監査証跡は利用可能ですか?
これらの質問は単なる技術的な詳細に関するものではありません。プラットフォームが本格的なビジネス統合に対応できるのか、それとも基本的な充電器管理にしか対応できないのかを判断するためのものです。
WebhookとAPI:オペレーターが両方を必要とする理由
多くの人があらゆる連携機能に対して「API」という言葉を使いますが、APIとWebhookには明確な区別があります。
APIは多くの場合、リクエストベースです。あるシステムが情報を要求し、別のシステムがそれを返します。例えば、ERPシステムが昨日のすべての課金セッションを要求する場合があります。
ウェブフックはイベントベースです。何らかの事象が発生した際に、システムが情報を送信します。例えば、CPMSは充電セッションが終了したとき、充電器がオフラインになったとき、または支払いが失敗したときに通知を送信する場合があります。
電気自動車の充電においては、どちらも有用である。
APIは、レポートの取得、レコードの同期、ユーザー権限の確認、履歴データの取得に適しています。一方、Webhookは、支払い確認、充電器アラーム、セッション完了、駐車料金の認証、メンテナンスのエスカレーションといったリアルタイムイベントの処理に適しています。
手動エクスポートのみをサポートするCPMSでは、本格的な運用には不十分です。APIとWebhookの両方をサポートするCPMSであれば、より複雑な運用にも対応でき、手作業を減らすことができます。
セキュリティとアクセス権限の管理
API統合はビジネス価値を生み出す一方で、セキュリティに関する責任も伴う。
充電プラットフォームには、ユーザー情報、支払い記録、エネルギーデータ、サイト収益、車両稼働状況、運用アラートなどが含まれる場合があります。すべてのサードパーティシステムがすべてのデータフィールドを閲覧できる必要はありません。すべてのパートナーがユーザーを作成したり、料金プランを変更したり、充電セッションを停止したりできる必要もありません。
これが、アクセス権限の管理が重要な理由です。
強力なAPIは、アクセストークン、スコープ付き権限、アカウントレベルの分離、安全な認証、監査ログ、明確なデータ境界をサポートする必要があります。大規模な事業者の場合、APIアクセスは業務上の役割ごとに分離されるべきです。駐車場システムでは、充電状況やナンバープレートのマッピングが必要になるかもしれませんが、完全な財務レポートは必要ありません。ERPシステムでは、請求記録が必要になるかもしれませんが、遠隔充電器制御は必要ありません。
購入者は、APIアクセスがどのように管理されているか、認証情報がどのようにローテーションされているか、ログがどのように保存されているか、サードパーティとの連携がどのように監視されているかをベンダーに問い合わせるべきです。
API統合におけるよくある間違い
よくある間違いの一つは、API統合を最終段階の技術作業として扱うことです。購入者が統合の詳細を尋ねる頃には、価格設定、サイト設計、運用ワークフローは既に確定している可能性があります。そうすると、後々問題が発生する原因となります。
もう一つの間違いは、「APIがある」ということは「あらゆるものと連携できる」という意味だと考えてしまうことです。APIが存在していても、ドキュメントが不十分だったり、範囲が限られていたり、Webhookが欠けていたり、テストが難しかったりする場合があります。
3つ目の間違いは、データの所有権を無視することです。事業者は、課金セッションデータ、決済データ、ユーザーデータ、レポートデータの所有者が誰であるかを把握しておく必要があります。プラットフォームがこれらのデータのエクスポートや統合を困難にしている場合、事業者はベンダーロックインに陥る可能性があります。
最後に、多くの事業者は例外処理の重要性を過小評価しています。実際の課金処理には、支払いの失敗、セッションの中断、オフラインの課金端末、返金要求、重複した記録、不完全なデータなどが含まれます。優れたAPIは、完璧な課金セッションだけでなく、こうした現実の状況にも対応できるものでなければなりません。
EV充電API統合プロジェクトの計画方法
優れたAPIプロジェクトは、通常、開発者会議ではなく、ワークフローマップの作成から始まります。
まず、接続が必要なシステムを定義します。これには、CPMS、決済ゲートウェイ、ERP、駐車場管理システム、CRM、車両管理ソフトウェア、作業指示プラットフォーム、レポートダッシュボードなどが含まれる場合があります。
次に、システム間で移動する必要のあるデータを定義します。各ワークフローについて、トリガー、データペイロード、受信システム、および期待される結果を特定します。
第三に、リアルタイムで実行する必要がある処理と、バッチ処理で実行できる処理を決定します。支払い状況、充電器の不具合、駐車場の利用状況などは、多くの場合、リアルタイムのワークフローが必要です。一方、月次財務報告書は、多くの場合、バッチ処理でエクスポートできます。
第4に、エッジケースをテストします。支払いが失敗した場合はどうなるでしょうか?駐車システムがオフラインになった場合はどうなるでしょうか?車両充電時間中に充電器が故障を報告した場合はどうなるでしょうか?ERPが請求書を拒否した場合はどうなるでしょうか?
最後に、ドキュメントの所有権について。各統合、各データフィールド、各例外、および各サポートプロセスには、それぞれ責任者が必要です。
これは技術的な話というより運用的な話に聞こえるかもしれませんが、まさにそこが重要な点です。API統合とは、単にソフトウェアを接続すること自体が目的ではありません。ビジネスに合った課金システムを構築することこそが重要なのです。
TrendPowerが通信事業者のコネクテッド充電ソフトウェア構築を支援する方法
電気自動車充電ネットワークを構築または拡張する事業者にとって、API統合は、バックエンド管理、課金、支払い、およびレポート作成と併せて評価されるべきである。
TrendPowerの EV充電バックエンドソフトウェア このコンテンツでは、充電器の通信、運用、複数拠点管理が実際のプラットフォーム上でどのように連携するかを説明しています。 EV充電料金請求ソフトウェア このガイドでは、課金業務の請求側について説明します。 EV充電決済ソリューション このガイドでは、支払い、ウォレット、決済、および財務報告に関するシナリオについて説明します。
製品ロードマップをまだ策定中の企業向けには、より広範なガイドとして、 EV充電管理ソフトウェア 運用担当者が、初期導入から大規模運用へ移行する際に、どのプラットフォーム機能が最も重要かを理解するのに役立ちます。
最も重要な点は、API統合を開発者専用の機能として扱うべきではないということです。それはビジネス上の議論の一部であるべきです。適切に連携する充電プラットフォームは、手作業を削減し、データ精度を向上させ、新しい収益モデルをサポートし、充電ビジネスの規模拡大を容易にします。
結論
EV充電APIの統合は、CPMSが実際のビジネス運用に対応できる状態にあることを示す最も明確な兆候の一つです。
事業者は充電器を監視するだけでなく、充電と支払い、請求、駐車場、ERP、CRM、車両管理システム、メンテナンスワークフローを連携させる必要があります。API連携がなければ、これらのプロセスは手作業となり、時間がかかり、エラーが発生しやすくなります。
適切に設計されたEV充電APIは、事業者がワークフローを自動化し、財務業務の負担を軽減し、充電器の稼働率を向上させ、フリート顧客をサポートし、駐車場へのアクセスを連携させ、より分かりやすいレポートを作成するのに役立ちます。また、一見完璧に見えても既存の業務システムに適合しないソフトウェアを、購入者が回避するのにも役立ちます。
EV充電プラットフォームを選ぶ際には、その機能だけでなく、接続可能な機器、公開できるデータ、送信できるイベント、権限管理の方法、そして導入前にチームが統合テストを実施できるかどうかについても確認しましょう。
そこで、API対応状況は単なる技術的な詳細事項ではなくなる。それは購入基準となるのだ。
よくある質問
EV充電APIとは何ですか?
EV充電APIとは、CPMS(顧客管理システム)や充電バックエンドが、決済ゲートウェイ、ERPプラットフォーム、駐車場システム、CRMツール、フリート管理ソフトウェア、レポートダッシュボードなどの外部システムとデータを交換できるようにするインターフェースです。
CPMSにAPI統合が必要な理由は何ですか?
CPMS(顧客決済管理システム)にはAPI統合が必要です。なぜなら、課金業務には支払い、請求、駐車、財務、顧客アカウント、車両管理、メンテナンスといったワークフローが関わることが多いからです。APIを利用することで、これらのシステムが手動でのデータエクスポートに頼ることなく連携して動作できるようになります。
EV充電APIはどのようなシステムに接続できますか?
EV充電APIは、決済ゲートウェイ、課金システム、ERPソフトウェア、駐車場プラットフォーム、CRMツール、車両管理システム、作業指示プラットフォーム、モバイルアプリ、ビジネスインテリジェンスダッシュボードなどに接続できます。
OCPPとEV充電APIの違いは何ですか?
OCPPは主にEV充電器と中央管理システム間の通信に使用されます。EV充電APIは通常、CPMSを決済、ERP、駐車場管理、車両管理ソフトウェアなどの外部ビジネスシステムに接続するために使用されます。
電気自動車の充電APIは決済連携に対応していますか?
はい。課金APIは、セッションデータを決済システムや請求システムに送信したり、決済状況の更新を受信したり、払い戻しをサポートしたり、請求書を作成したり、決済ワークフローを管理したりするのに役立ちます。
電気自動車の充電システム統合において、Webhookが重要な理由は何ですか?
Webhookを使用すると、CPMSは、充電セッションの終了、支払いの失敗、充電器のオフライン化などの重要なイベントが発生した際に、外部システムに通知できます。これにより、リアルタイムの自動化が可能になります。
CPMS APIを選択する前に、オペレーターはどのような点を考慮すべきでしょうか?
オペレーターは、APIがリアルタイムのWebhook、セッションデータ、請求記録、ユーザーデータ、充電器の状態、障害アラート、サンドボックステスト、ロールベースの権限、ドキュメント、バージョン管理をサポートしているかどうかを確認する必要があります。
EV充電APIは、フリート充電に対応できますか?
はい。車両充電APIは、充電セッションを車両ID、ドライバーアカウント、デポスケジュール、コストセンター、ルートプランニング、および車両レポートシステムに接続できます。
