> ## Documentation Index
> Fetch the complete documentation index at: https://developer.kyckr.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Async Order Pattern for Enhanced Profile: Pending Response on GET

> The V1 Enhanced Profile async order pattern: a slow GET request returns a pending-response body instead of timing out, tracked via the V1 order-status endpoint.

## Overview

We're introducing a **pending-response fallback** on `GET /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](/company-v2/developer-news/2026-08-async-order-pattern).

**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 the `GET` 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

```mermaid theme={null}
sequenceDiagram
    participant C as Client
    participant A as Kyckr API
    participant U as Profile URL

    C->>A: GET /core/company/profile/{countryISO}/{companyCode}
    alt Fast path
        A-->>C: 200 OK, profile data
    else Slow path
        A-->>C: 200 OK, pending-response body with transactionIdField
        loop Poll with backoff
            C->>A: GET /core/filing/order-status/1
            A-->>C: array of ProductListItem
            C->>C: Find item where productOrderIdField == transactionIdField
        end
        C->>U: GET urlField (when statusField = 2, 21, or 3)
        U-->>C: Enhanced profile document
    end
```

Both branches return `200`. 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 is `200 OK` with this body:

```json theme={null}
{
  "transactionIdField": "10818754",
  "responseCodeField": "100",
  "responseDetailsField": "The company profile is still being processed and will be delivered when ready."
}
```

The `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:

```text theme={null}
GET /core/filing/order-status/1
→ array of ProductListItem

Find item where productOrderIdField == "10818754"
Check statusField: when it indicates completion,
  retrieve profile from urlField or structuredDataUrlField
```

### Status values (order-status response)

| `statusField`  | Meaning                                                     |
| -------------- | ----------------------------------------------------------- |
| `1`            | Pending: order in progress                                  |
| `2`, `21`, `3` | Ready: retrieve from `urlField` or `structuredDataUrlField` |
| `5`            | Failed                                                      |
| `9`            | Cancelled                                                   |

See the [Order Documents guide](/documentation/features/retrieve-a-document-v1) 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.

Whether `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 the `transactionIdField` 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.

## Additional resources

* [Company V1 API Reference](/company-v1/api-reference/overview)
* [Company V1 Changelog](/company-v1/api-reference/changelog)
* [Order Documents guide](/documentation/features/retrieve-a-document-v1)
* [Luxembourg country guide](/country-guides/luxembourg)
* [Enhanced Profile guide](/documentation/features/perform-a-kyb-check-v1)