A charging network generates a constant stream of events: sessions starting and ending, connectors changing status, meter values ticking, firmware applying, faults appearing. Almost every serious integration question we get eventually reduces to: how do we get those events into our own systems, reliably, as they happen?
The AmpNexus platform offers two complementary answers — webhooks and Server-Sent Events (SSE) — and choosing between them is easier once you're clear about what each is actually good at.
The two models in one minute
Webhooks are push-to-you: you register an HTTPS endpoint, and the platform POSTs each event to it as JSON. Your receiver is a normal web handler; delivery is per-event with retries.
Server-Sent Events are pull-then-stream: your service opens a long-lived HTTP connection to the platform and events arrive as a continuous stream over that connection. One socket, many events, minimal overhead per message.
Rendering diagram…
When webhooks are the right tool
Webhooks shine when events trigger discrete business processes:
- A
session.completedevent that creates a billing record - A
chargepoint.faultevent that opens a ticket in your service desk - A
rollout.finishedevent that posts to a Slack channel
Their strengths map to that shape. Each delivery is independent, so one slow consumer doesn't block others. Retries with backoff mean a short outage on your side heals itself. And because the receiver is a plain HTTPS endpoint, every language, framework, serverless runtime and iPaaS tool on earth can consume them.
The costs are operational: you're running a public endpoint, so you must verify signatures (every AmpNexus webhook is signed; verify before trusting), respond quickly (accept, enqueue, return 2xx — never do the work inline), and design for at-least-once delivery. That last one is non-negotiable: retries mean duplicates, so consumers must be idempotent. Key on the event ID, not on "we probably won't see this twice".
When SSE is the right tool
SSE shines when you want a live view of a lot of state:
- A wallboard in your NOC showing connector status across the estate
- A digital-twin service mirroring charger state into your own datastore
- Ops tooling that reacts to meter values or status flaps within seconds
Here the per-event overhead of webhooks (a TLS handshakey HTTP POST per meter value, across thousands of connectors) becomes silly, while a single streaming connection carrying everything is cheap and low-latency. There's no public endpoint to secure on your side — the connection is outbound from your infrastructure with your credentials — which some security teams strongly prefer.
The costs are the mirror image: you own the connection lifecycle. Streams drop — networks blip, load balancers recycle, deploys restart consumers — so a production SSE consumer reconnects automatically and resumes from the last event ID it processed, rather than assuming the stream is a perfect record. Treat the stream as a low-latency view, not as your source of truth.
The pattern we recommend: both, with a reconciliation loop
Mature integrations rarely choose one. The shape that holds up in production:
- Webhooks for money and workflows. Anything that creates a financial record or triggers a process runs on signed, retried, idempotent webhook deliveries.
- SSE for live operational state. Dashboards and mirrors consume the stream, accepting that a dropped connection means a brief gap.
- A periodic reconciliation sweep. A scheduled job queries the REST API (for example, sessions in the last 24 hours) and compares against what your systems recorded. This is your safety net for the events no push mechanism can guarantee you'll never miss.
That third leg is the one teams skip and later regret. Push delivery — of any kind, from any vendor — is a latency optimisation, not a durability guarantee. The API is the source of truth; the streams keep you current between reconciliations.
A note on payload discipline
Whichever transport you use, resist the temptation to treat event payloads as your data model. Payloads evolve — fields get added, enrichments appear. Consume them tolerantly (ignore unknown fields), persist the identifiers, and fetch the full resource from the API when you need the complete, current picture. Integrations built this way survive platform evolution without a rewrite.
Both transports are documented in the AmpNexus API reference, and every event category — sessions, status, rollouts, Cortex alerts — is available over each. If you're wiring up an integration and want a second pair of eyes on the architecture, talk to us; it's a conversation we enjoy.