Home / CAN protocol API

CAN protocol APIYou keep the definitions. We deliver the values.

The requirement that ends projects early

When a supplier opens with "send us your CAN protocol", the project acquires an internal approval it did not have a week earlier. Protocol documents describe product behaviour; they are reviewed, versioned and restricted. The delay is not reluctance — it is process.

What we ask for instead

A list. Four columns:

Value — what to report, named in the customer's language.
Unit — bar or kPa, Celsius, hours, counts.
Interval — how often each value is worth a message.
Destination — platform endpoint, fleet system, file, ERP interface.

The customer builds the internal mapping from its own signals to that list. Nothing else leaves the organisation: no protocol document, no DBC file, no firmware.

What the API covers

Action	What it does
Scheduled query	Sample named values at an interval chosen by the platform.
Monitored upload	Push values when they change, with a heartbeat in between.
Parameter set	Change CAN bitrate and sample points remotely.
Firmware action	A/B dual-partition FOTA with resume and rollback.
Pass-through	Reach an attached ECU / VCU for parameter or upgrade work (custom scope).

How the first payload arrives

Two engineers agree on five field names and one interval, and a number starts arriving — usually within about a day of joint work. The schedule that follows is not ours: it is how long the platform side needs to consume the payload.

What we will not claim

We do not assert compatibility with any named fleet platform. Integration is a documented payload contract, agreed per project, not a logo on a slide. If the customer's platform team wants a specific transport, say so early and it is settled in the contract.

Telematics integration for the PLC / SCADA / MQTT paths, or the DTU page for the hardware.

Data sheet, interface list and a payload example on request — contact us (ralph@gz-can.com · +86 130 7692 2278).

The commercial problem this solves

If a supplier asks you to hand over your CAN protocol before they can quote, you have just given away the thing that makes your machine different. Most buyers feel this and cannot articulate it, so they either refuse and lose the supplier, or hand it over and accept the risk.

Our model is the other way round. You keep the protocol; we deliver the values. You tell us what to read and where to put it; the unit ships configured to publish a payload you define. The protocol document never has to leave your building.

What "API" means here, precisely

It does not mean a REST service we host and you call - that would put us in the middle of your data path permanently. It means a documented contract between the unit and your endpoint:

How a first payload gets agreed

That sequence is deliberately boring. The alternative - agree verbally, ship, discover the units differ - is what makes telematics projects expensive.

What you get at the end

A payload you can parse, a broker you control, and a unit that can be reconfigured remotely when the requirement changes. The CAN definitions remain yours, which means the next supplier you talk to does not inherit a copy of your machine's logic.

Questions about the payload and the API

Is this a REST API you host?

No. We are not in the middle of your data path. The "API" here is a contract between the unit and your endpoint: a payload with named fields, over MQTT or HTTP, to a broker or endpoint you control.

Who owns the field names?

You do, if you want them. The default payload has our field names; an OEM configuration carries yours, so your platform does not need a translation layer. Changing them later is a configuration change, not a new hardware order.

What if our platform expects a schema we already use?

Send the schema with the values you need and we will say plainly whether it maps directly, maps with a transformation on your side, or needs a firmware variant. The third answer is the expensive one, and it is better to hear it before the order than after.