Signing within the manufacturer workflow

eCoC XML signing and API integration

An eCoC signing workflow links a reviewed XML file to the authorised signing entity and returns a signed version for delivery. Electronic COC coordinates that process with certificate preparation and release review. The trust service, certificate and receiving interface must be agreed for the manufacturer’s actual use case.

Request a workflow demoExplore the platform
01

Decide who signs and what is being signed

Start with the issuing entity, the applicable destination requirements and the exact XML version. Electronic signatures identify a natural person; electronic seals concern a legal person. The required form and level must be checked for the destination. Electronic COC is the workflow platform; qualified certificate issuance belongs to the relevant trust service provider.

  • Identify the authorised entity and certificate owner.
  • Confirm the signature or seal profile required by the recipient.
  • Release only the reviewed XML version to the signing step.
02

Define the eCoC signing API contract before connecting it

Different signing services accept different inputs and return different evidence. Establish whether the contracted service expects a document or another defined payload; do not assume an arbitrary XML file or digest can be sent to every endpoint. Confirm authentication, request identifiers, timeout handling and the returned signed output against the provider’s documentation.

  • Input: the approved payload and a stable request reference.
  • Output: the signed file or the documented response needed to assemble it.
  • Failure: a traceable result that prevents an unsigned file from moving forward.
  • Retry: reconciliation with the previous request before submitting another operation.
03

Keep signing, verification and submission distinguishable

A successful API response alone does not describe the full outcome. Review the signed result, associate it with the vehicle and document version, and preserve the verification evidence required for your process. Then hand that version to the destination-specific delivery workflow. Record the receiving result separately so teams can see where a problem occurred.

04

Prove the proposed integration with a controlled sample

Bring your signing provider, available test environment, target authority and a sanitised XML sample to the scoping discussion. Evaluate the normal path, a rejected request, a timeout and a corrected document. Production activation depends on the agreed service contract, account configuration and successful project-specific testing.

Questions and answers

Does Electronic COC issue qualified signing certificates?

No. Electronic COC coordinates the manufacturer’s certificate workflow. Certificate issuance and the qualified trust service are handled by the appropriate provider under the agreed arrangement.

Can our existing signing API be used?

It can be assessed during integration scoping. Confirm the supported payload, signature profile, authentication method, test access and returned evidence before committing to a connection.

Can the XML change after signing?

A change to signed content requires a new controlled review and signing cycle. Keep the earlier and corrected versions distinguishable and reconcile any submission already made.

Official references

Reviewed . Requirements are defined by the linked authorities and service documentation.

Continue through the eCoC workflow

IVI 2.0 XML validation for eCoC

Plan IVI 2.0 XML validation around schema checks, vehicle data review and release decisions. Identify what must be corrected before signing and submission.

Scope your eCoC signing integration

Tell us your signing provider, issuing entity and target delivery route. We will clarify the payload, responsibilities and test evidence needed for the workflow.

Request a workflow demo

Review implementation scope and pricing