EUDR API V3: what your ERP must send TRACES by 30 December

The EUDR API your ERP has to call before 30 December 2026 is V3: a SOAP service behind WS-Security that accepts plot geolocation only as base64-encoded GeoJSON. The Commission says V1 and V2 will be retired when V3 is released. This guide covers what the payload carries, which GeoJSON rules quietly corrupt data, and how to build against a spec the Commission itself says may not be final.

The deadline itself is now fixed in law. Regulation (EU) 2025/2650, published in the Official Journal on 23 December 2025, makes the core obligations of Regulation (EU) 2023/1115 apply from 30 December 2026. The integration work is what remains open. The facts below are as of October 2026.

The regulation covers seven commodities: cattle, cocoa, coffee, oil palm, rubber, soya and wood. For Indian exporters, coffee and rubber are the ones that matter. Shrimp and other seafood are not on the list.

Is the EUDR API SOAP or REST? SOAP, and the security header is where first calls fail

The EUDR Information System exposes SOAP web services only. The operator API reference lists a production base URL at https://eudr.webcloud.ec.europa.eu/tracesnt/ and an acceptance base URL at https://acceptance.eudr.webcloud.ec.europa.eu/tracesnt/, with three services:

Authentication is a WS-Security UsernameToken over HTTPS, with a PasswordDigest rather than a plain password, a required timestamp (wsu:Created and wsu:Expires), and a WebServiceClientId header. The username comes from your EU Login profile, and the authentication key comes from the "Web Services Access" section of your profile, according to the credentials guide. The digest follows the OASIS UsernameToken Profile: Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) ).

This is the security header from the Commission's Echo service sample request, copied as published:

<soapenv:Header>
    <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
                   xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
        <wsu:Timestamp>
            <wsu:Created>2026-01-15T10:00:00.000Z</wsu:Created>
            <wsu:Expires>2026-01-15T10:05:00.000Z</wsu:Expires>
        </wsu:Timestamp>
        <wsse:UsernameToken>
            <wsse:Username>your-username</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">digest-value</wsse:Password>
            <wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">nonce-value</wsse:Nonce>
            <wsu:Created>2026-01-15T10:00:00.000Z</wsu:Created>
        </wsse:UsernameToken>
    </wsse:Security>
    <base:WebServiceClientId>YOUR_CLIENT_ID</base:WebServiceClientId>
</soapenv:Header>

The base prefix is declared on the envelope in that sample as http://ec.europa.eu/sanco/tracesnt/base/v4. Three details from the Commission's own pages will save you a day each:

• Line-wrapped Base64 fails silently. Many Base64 libraries wrap output at 76 characters. If a line break lands inside wsse:Password or wsse:Nonce, the service returns a bare InternalSystemException fault and logs nothing on its side, per the troubleshooting page.
• Clock skew counts. wsu:Created must be within 5 minutes of server time, so run NTP on whatever host signs the request (Echo service reference).
• Echo exists only in acceptance. To verify production, the Commission suggests a real call with restrictive filters. An empty, successful response confirms your credentials and network path.

If one API user acts for several operators, which is the usual setup for a software provider or a group with several legal entities, every business call needs a BodyIdentity header carrying an OperatorAccessIdentifier. That child element must be unqualified (no namespace prefix). Without the header, a multi-operator request is rejected. Echo ignores the header, so it can't tell you whether you've configured it correctly. Operators created before the feature existed have to request the identifier from SANTE-TRACES@ec.europa.eu.

What EUDR API V3 changed for anyone who built against V2

V3 is a redesign, not a patch. The V2 to V3 migration guide merges the separate V2 submission and retrieval services into a single EUDRDueDiligenceStatementServiceV3 endpoint, under a new namespace: http://ec.europa.eu/tracesnt/certificate/eudr/due-diligence-statement/v3.

Two quieter changes catch typed clients. ddsIdentifier is renamed uuid everywhere. The change log also adds SUSPENDED, UPDATED, GROUPED and OBSOLETE to the status enum and warns that new enum values "may require client-side updates to avoid unmarshalling errors". Statements submitted before the amendment stay readable through V3 in read-only mode.

What the due diligence statement payload has to carry

A V3 submitDds call wraps an operatorRole and a statement. The DDS V3 reference defines the statement's required fields as activityType (IMPORT, EXPORT or DOMESTIC), commodities and geoLocationConfidential, a boolean that controls whether geolocation is disclosed down the supply chain. Each commodity carries an HS heading of 2 to 10 digits and a commercial description. Each producer carries an ISO 3166-1 alpha-2 country and a required geometryGeojson field, typed base64Binary.

The validation rules add the limits your ERP has to enforce before it submits:

• An operator not established in an EU country may only use the IMPORT activity, and IMPORT or EXPORT requires an EORI number.
• Net mass is mandatory for IMPORT and EXPORT.
• No more than 100 commodities per statement, 1,000 producers per commodity and 10,000 producers per statement.
• No more than 2,000 referenced statements per statement.
• Geolocation data may not exceed 25 MB per statement.

Your ERP also needs to work around time limits. A statement can be amended or withdrawn within a 72-hour window. After that, a change means a new submission with a new identifier. Once customs has used the statement for clearance, it's locked. The usage guidance asks you to wait at least 30 minutes after submitting before you poll for status. It also sets a limit of 5 calls per second per IP. Plan for an asynchronous job and a status table, not a synchronous button.

EUDR GeoJSON rules that will bite your data team

EUDR GeoJSON must use WGS 84 (EPSG:4326), with coordinates in longitude, latitude order. The same rules apply to the web UI and the API, according to the GeoJSON file description. Most of the failures we'd expect come from data that looks valid:

• Precision. The system truncates coordinates to 6 decimal places, and the spec warns that extra precision can turn a valid shape into an invalid one. Two points that differ only beyond the sixth decimal collapse into duplicates. Meanwhile the DDS reference asks for "minimum 6 decimal digits". Send exactly six.
• Polygons. A polygon needs at least four coordinate pairs, and its first and last pairs must match. Holes, crossing lines and LineString geometries are rejected.
• Points and area. A Point without an Area property defaults to 4 hectares. A Point area above 4 hectares raises an error for anything except cattle, and any area provided must be at least 0.0001 ha. Plots above 4 hectares need polygons.
• Types. "Area": "3" is read as 0, because a quoted number isn't treated as a number.
• Case. Property names are case-sensitive: productionplace is not ProductionPlace.
• Size. All GeoJSON in one statement shares a 25 MB limit. The Commission suggests trimming points along straight edges and using single points for plots under 4 hectares.

One warning about copying the spec. Its own single-Feature example gives a Point with nested brackets, [[-105.029865, 40.622831]], which is not how RFC 7946 defines a Point position. Use the FeatureCollection examples instead. Here is a minimal Type I file in that shape. The property names come from the spec, and the coordinates are illustrative:

{"type":"FeatureCollection","features":[
 {"type":"Feature",
  "properties":{"ProductionPlace":"PLOT 01","ProducerCountry":"IN"},
  "geometry":{"type":"Polygon","coordinates":[[[75.801234,12.401234],[75.805678,12.401234],[75.805678,12.405678],[75.801234,12.405678],[75.801234,12.401234]]]}},
 {"type":"Feature",
  "properties":{"ProductionPlace":"PLOT 02","Area":1.5,"ProducerCountry":"IN"},
  "geometry":{"type":"Point","coordinates":[75.812345,12.412345]}}
]}

Validate that file in your own pipeline, then base64-encode it into geometryGeojson. Don't leave the rejection to TRACES.

Who files: downstream operators, simplified declarations and Indian exporters

Downstream operators don't submit a due diligence statement. Regulation 2025/2650 defines a downstream operator as anyone who places on the market or exports products made from relevant products that are all already covered by a statement or a simplified declaration. The API FAQ says their duty is to collect and keep supplier information, reference numbers or declaration identifiers, and buyer information for at least five years.

A simplified declaration is a one-time filing by a micro or small primary operator: a natural person or small business, established in a low-risk country, selling what it grew itself. It may use a postal address instead of GeoJSON. In return it gets a declaration identifier, which travels with the goods in place of a DDS reference number. India is on the low-risk list in Implementing Regulation (EU) 2025/1093. That makes the simplified route available in principle to Indian growers who themselves place coffee or rubber on the EU market or export it. It doesn't help a curing works or trader that buys from growers.

For most Indian coffee and rubber exporters, the statement is filed by the operator placing the goods on the EU market, or by an authorised representative established in the Union. In practice, that usually means your EU buyer. The non-EU-operator rule above points the same way. Either way, your job is to hand over plot geolocation that passes the rules above. Also watch the product scope: the Commission's May 2026 package proposes adding soluble coffee through a draft delegated act.

How to connect to the EUDR API: build to V3 now, design for the spec to move

The case for waiting is real. The operator reference says the documentation "may not be final" while the amendment of Implementing Regulation (EU) 2024/3084 is under way. Grouping and simplified-declaration versioning may not be in the first release. The change log says mTLS authentication is planned for a later release, with UsernameToken kept during a transition. On that reading, building now means building twice.

We'd still build now, for two reasons. The legal date is fixed, and the Commission's 4 May 2026 simplification package brought guidance, a draft delegated act and an updated draft implementing act on the Information System, not a new date. And V1 and V2 go away when V3 ships, so there's no older version to fall back on. To keep the rework small, build like this:

1. Get acceptance credentials first. The credentials guide recommends finishing setup and testing in acceptance before you repeat the process for production. Run Echo, then a real DDS with real plot data.
2. Generate the client from the live WSDL and XSDs (replace ?wsdl with ?xsd=1, ?xsd=2), and regenerate whenever the Commission publishes an update.
3. Isolate transport and authentication behind one adapter, so the move to mTLS is a change in one place.
4. Make enum handling tolerant, so a new status value is logged rather than crashing deserialisation.
5. Treat geolocation as master data on the supplier or plot record, validated against the rules above, rather than as an attachment on the shipment.
6. Store your internalReferenceNumber alongside the returned uuid, then reconcile with getDdsByInternalReference.

This is the wrong choice if you file a handful of statements a year. The TRACES web UI applies the same validation, and an API integration won't pay for itself at that volume. It's also the wrong choice if your plot data isn't clean yet. Fix the GeoJSON first, because the API adds nothing to bad coordinates.

A word on where we stand. We have not shipped a TRACES integration, and everything above comes from the Commission's published spec. We have built the system on the other side of it: a custom ERP for a large industrial client that unified HR, CRM, inventory and finance. The shape is also familiar from GST e-invoicing, where an ERP must produce a schema-valid payload for a government system and keep what comes back. If you are scoping this as custom ERP development or as a standalone adapter through our API development and integrations practice, budget for the data cleanup, not just the SOAP client.

The next decision is a small one, and it's due this week: who in your organisation owns the EU Login account that will hold the authentication key. Under Regulation 2025/2650, the maximum fine for a legal person must be at least 4% of its total annual Union-wide turnover. With stakes like that, the owner of that key shouldn't be whoever happened to sign up first.