The DGFT Certificate of Origin API 2026 is now available for eligible exporters that want to connect ERP, accounting or other business software directly with the government’s Certificate of Origin system. The new Open API route can reduce repeated manual data entry by allowing integrated systems to authenticate, submit Certificate of Origin information, receive certificates and verify issued certificates through DGFT’s Trade Connect infrastructure.
This is a real workflow change, but it does not make Certificate of Origin approval automatic, remove rules-of-origin requirements or guarantee faster approval. Exporters still have to meet the applicable agreement, scheme and origin conditions.
DGFT CoO API integration path
- Confirm that your exporter account is eligible for API access. DGFT’s public announcement uses the term “eligible exporters”, but the finer eligibility boundary was not fully established from the reviewed public material.
- Obtain API credentials through the Certificate of Origin API Management route.
- Register the source IP addresses that your ERP or business system will use to call the DGFT service.
- Authenticate through the token API. DGFT says the access token is valid for 60 minutes.
- Digitally sign the required exchanges using the security model specified by DGFT.
- Submit and receive Certificate of Origin files through the CoO File API.
- Track transaction states such as Draft, In Process, Approved, Certificate Issued or Rejected.
- Verify issued certificates through the Certificate Verification API.
What changed on September 7?
DGFT introduced an Open API facility for Certificate of Origin processing through the Trade Connect e-Platform. The government says the facility is now available to eligible exporters and allows direct integration between an exporter’s ERP, accounting or other business system and the DGFT Certificate of Origin infrastructure.
Before this integration route, exporters could hold shipment, invoice and product data inside their own business systems but still need to repeat relevant information in the government Certificate of Origin workflow. The API route is intended to reduce that duplicate entry for integrated exporters.
Is the DGFT Certificate of Origin API live now?
Yes. The September 7 government communication describes the facility as available now to eligible exporters and their systems. It should therefore not be described as merely a future proposal or pilot announcement.
Who can use the API?
The official material reviewed by TPS says the facility is available to eligible exporters. It does not provide enough public detail in the reviewed source set to safely define every eligibility condition, exporter tier, volume threshold or approval requirement.
Exporters should therefore confirm their current API-access eligibility inside DGFT’s Trade Connect/Certificate of Origin environment before committing development resources.
Does it support both preferential and non-preferential Certificates of Origin?
Yes. DGFT says the Open API framework covers both preferential and non-preferential Certificates of Origin.
That does not mean every shipment automatically qualifies for preferential treatment. The relevant FTA, PTA, CEPA, CECA or other origin scheme still determines the substantive origin requirements.
Which three APIs has DGFT described?
| API | What it does |
|---|---|
| Authentication Token API | Authenticates the integrated exporter system and provides the access token required for API communication. |
| CoO File API | Supports Certificate of Origin application/file submission and receipt of certificate-related output through the integrated workflow. |
| Certificate Verification API | Allows issued Certificate of Origin records to be verified electronically. |
Where do exporters get API credentials?
DGFT’s public guidance points exporters to the API Management area of the Certificate of Origin system. The exporter or integration team needs the current DGFT registration and authentication material before calling the APIs from production software.
TPS did not establish a reliable public onboarding-time guarantee, so businesses should not assume credentials will be issued immediately.
Do source IP addresses have to be registered?
Yes. DGFT’s published architecture requires the source IP addresses used by the exporter’s integrated system to be registered or whitelisted.
This matters for implementation teams because production calls should come from the expected registered infrastructure. TPS did not establish the maximum number of IPs, the change process for replacing an IP or whether special arrangements apply to dynamically addressed infrastructure.
How does authentication work?
DGFT describes a token-based authentication process. The published material says an access token is valid for 60 minutes.
Integration teams should therefore design around token expiry rather than assuming one credential exchange remains active indefinitely. The detailed retry and renewal behaviour should follow the current DGFT technical manual rather than assumptions made from the high-level announcement.
How are API exchanges secured?
DGFT says the system uses SHA-256 RSA digital signatures with 2048-bit X.509 certificates, along with measures including PBKDF2-protected passwords, token controls and source-IP restrictions.
Those requirements make the integration more than a basic username-and-password connection. ERP or middleware teams need to account for certificate storage, signing and secure credential handling as part of production deployment.
How can exporters track a submitted Certificate of Origin?
DGFT describes a transaction ledger that can expose processing states including:
- Draft
- In Process
- Approved
- Certificate Issued
- Rejected
This gives the exporter or compliance team an important distinction between a successful technical submission and a completed Certificate of Origin outcome. A submitted file is not the same as an issued certificate.
Does API submission guarantee Certificate of Origin approval?
No. Nothing in the reviewed evidence supports automatic approval. The API automates the exchange of application and certificate data; the relevant Certificate of Origin rules and validation requirements continue to control the outcome.
An ERP can therefore successfully submit an application that is later rejected because the substantive origin or document requirements are not satisfied.
Does the API remove rules-of-origin requirements?
No. The API is a technology and workflow integration layer. It does not change whether goods qualify as originating under a particular trade agreement or scheme.
DGFT says the system continues to apply the relevant origin criteria and validation logic associated with the selected agreement or Certificate of Origin scheme.
Which agreements and schemes are covered?
The September 7 government material lists a broad set of preferential arrangements and schemes, including Japan CEPA, Korea CEPA, SAFTA, SAPTA, ASEAN-India FTA, Singapore CECA, Malaysia CECA, Chile PTA, Mercosur PTA, UAE CEPA, Australia ECTA, Oman CEPA, EFTA TEPA, UK CETA, GSP and Non-Preferential Certificate of Origin processing.
Exporters should still verify the current agreement list in DGFT’s live system because agreement availability can expand or change after publication.
What type of exporter benefits most from ERP integration?
The practical value is likely to be highest for exporters that repeatedly prepare Certificates of Origin and already hold the required shipment, commercial-invoice, product and trade data inside an ERP or accounting environment.
A business filing only occasional Certificates of Origin may decide that a full software integration is not worth the implementation and maintenance cost. The API is an integration option, not evidence that ordinary portal use has become invalid.
What should an ERP or IT team verify before starting?
- Whether the exporter account is currently eligible for API access.
- Where current API credentials are issued and managed.
- Which production source IPs must be registered.
- How the 60-minute authentication token is obtained and refreshed.
- How the required X.509 certificate and RSA signing process will be implemented securely.
- Which CoO fields must map from the ERP to the DGFT payload.
- How transaction IDs and states will be stored for audit and reconciliation.
- How issued certificates will be received and independently verified.
- How technical failures will be separated from substantive Certificate of Origin rejection.
Where is the detailed implementation guidance?
DGFT says registration, authentication and integration information is available through the Certificate of Origin section of Trade Connect and that a step-by-step help manual is annexed to Trade Notice No. 25/2026-27.
The detailed technical manual should control code-level implementation. The public release is sufficient to establish the architecture, but TPS does not treat it as a substitute for the current API schemas, required payload fields or official error handling.
What remains unknown for developers?
The reviewed authoritative material did not establish several implementation details strongly enough for TPS to publish them as fact, including API rate limits, concurrency limits, sandbox or test endpoints, the complete error-code catalogue, certificate rotation procedure and production onboarding service levels.
Those details should be taken from the current DGFT technical manual or subsequent implementation guidance rather than inferred from general API practice.
Verification note
ThePulseSignal reviewed the September 7 DGFT/Ministry of Commerce announcement and current same-day coverage describing the Open API architecture, authentication requirements, signing model, supported Certificate of Origin workflow and transaction states. The central claim that an ERP-to-DGFT Certificate of Origin integration route is now available is confirmed, while code-level implementation details remain dependent on the current DGFT manual.
Limitations and unresolved facts
The exact definition of an eligible exporter, full endpoint and payload specifications, API rate limits, sandbox availability, detailed error handling, certificate renewal procedures and production onboarding timelines were not fully established from the reviewed public evidence. The API also does not establish automatic Certificate of Origin approval or relax agreement-specific rules of origin.
