Overview
We’re introducing a pending-response fallback onGET /core/company/profile/{countryISO}/{companyCode}: an order the registry can’t fulfil in time returns a 200 response carrying a transactionIdField and a processing message, instead of timing out, and the profile is retrieved through the V1 order-status workflow.
V1 does not support POST Enhanced Profile; the pending-response fallback on GET is V1’s async order pattern. On V2, Enhanced Profile can also be ordered asynchronously from the start with POST + poll; see the V2 release note.
Action required: once this is live, your integration needs to handle the pending-response body on GET.
Jurisdiction rollout
The pending-response fallback is enabled per jurisdiction: it applies only where the jurisdiction is served by theGET profile endpoint and fulfilment has shown a tendency to run long enough to time out.
Luxembourg is the only such jurisdiction today. A GET request for LU returns 200 either way: the profile itself, or a pending-response body carrying a transactionIdField to retrieve the profile once available. For other jurisdictions you should not see the pending-response body under normal conditions.
Background: the GET route
GET /core/company/profile/{countryISO}/{companyCode} holds the connection open while the registry fulfils the order. Most fulfilment completes quickly; a slow order can hold the connection far longer before eventually timing out, and a timed-out request loses its result. A GET request typically has a person waiting on it, so rather than hold toward that timeout, the fallback draws the line at ~40 seconds: if the profile hasn’t arrived, the request returns 200 with a pending-response body instead, carrying a transactionIdField, and the profile is retrieved once fulfilment completes.
Flow overview
Both branches return200. There’s no separate status code to switch on: check the response body. A pending response carries transactionIdField and a processing message, and has no profile payload.
Handling the pending response
A pending response is200 OK with this body:
transactionIdField is the same value as productOrderIdField in the order-status list response; the field name differs across the two endpoints.
Polling for completion
orderedWithin is the number of days to look back for orders. Integer, range 0 to 30, where 0 means today. Choose a window comfortably wider than your expected fulfilment time; orderedWithin=1, the last 24 hours, is sufficient for any order that completes within minutes.
Poll GET /core/filing/order-status/{orderedWithin} and scan the returned array for the item whose productOrderIdField matches the transactionIdField from the pending response:
Status values (order-status response)
See the Order Documents guide for the canonical reference on V1 order status values.
Polling cadence: use exponential backoff: start with a short interval and increase it up to a sensible cap. Delivery timeframes vary considerably by jurisdiction: review the expected timeframe for each jurisdiction you order from, and size your backoff intervals and upper limits to match. Treat orders still showing a Pending status after your tolerance window as having exceeded it: investigate or contact support. Don’t poll on a tight loop; the order-status endpoint is shared across products and aggressive polling will degrade your other API calls.
Result retrieval
When the order completes, the result is available via two URL fields:urlField: the document/profile artifact URL.structuredDataUrlField: a structured-data version of the result, where available.
structuredDataUrlField is populated depends on jurisdiction and product. Check both fields and fall back from one to the other if your integration prefers a specific format.
Recovering a lost transaction ID
If your process loses thetransactionIdField after receiving a pending response, don’t re-issue the request: that creates a new order placement and is billed separately. Instead, recover it from the order-status list by filtering on your orderRef, or by scanning recent items.