CAN protocol API — your protocol stays yours

Why the protocol question stops projects

Most telematics projects stall on one sentence: we need your CAN protocol. For an OEM that sentence means releasing internal documentation to an outside supplier, which needs internal approval, which takes months. So the project waits — not because the hardware is wrong, but because the handover is unacceptable.

Our answer: we never ask for it

Your CAN protocol stays with you. You define and hold the frames and signals. What we ask for is much smaller: which data points you want reported, in what unit, and where they should go. We build to that list and deliver the values through an API your side calls.

• No protocol document required — nothing leaves your organisation.
• No DBC handover required — the mapping stays internal to you.
• No firmware release to us — we work at the data boundary, not inside your controller.
• You stay portable — the API contract is yours, so changing supplier later is a manageable project rather than a rewrite.

What the API actually does

• Scheduled CAN queries — ask the unit to sample specific data at a chosen interval.
• Monitored upload — values are pushed when they change, instead of streaming everything continuously.
• Remote parameter change — CAN bitrate and sample points adjusted remotely, so one unit can serve different machine models.
• Remote firmware actions — A/B dual-partition FOTA with resume and automatic rollback.
• ECU / VCU upgrade through CAN pass-through — custom scope, agreed per project.

How long integration takes

The first working data point is usually reachable in about one day of joint work, because the interface is the API and not your protocol. The schedule that matters after that is not ours: it is how long your side needs to consume the payload. We will give a written scope before the first line of code — no pricing on this page; ask for a quotation.

Questions worth asking any supplier

• Do you require my CAN protocol or DBC file? (If yes, the approval path is on the critical path.)
• Is the API documented, and can I see a payload example before the order?
• Who maps my internal signals to your payload?
• What happens to data when connectivity drops?

See the CAN-to-4G telematics page for the hardware side, or CAN bus telematics for the interface options.

FAQ

Do you need my DBC file?

No. The signal mapping stays on your side; we work from the data points you expose.

Is the API documented before I order?

Yes — we will send a payload example and the field list so you can judge the fit first.

What if my platform expects a different schema?

Tell us the target fields; the mapping is agreed in writing before integration.