> ## 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.

# Changelog

> Version history and changes to the Kyckr Companies V2 API.

Changes to the Companies V2 API contract, newest first. Use the tag filters to narrow the list.

<Update label="2026-06" tags={["Enhanced Profile", "Orders", "Preview"]}>
  🚧 **Preview — in development, not yet available in production.**

  **Async order pattern for Enhanced Profile**

  Slow-running orders (jurisdictions where upstream fulfilment exceeds the \~40s connection-hold window) will have a documented async path on both `GET` and `POST` Enhanced Profile.

  * `POST /companies/{kyckrId}/enhanced` will be the recommended pattern for production integrations — returns an `orderId` immediately with no server-side connection hold. Poll `GET /orders/{orderId}` to retrieve the profile when ready.
  * `GET /companies/{kyckrId}/enhanced` will remain as a convenience pattern. The server holds the connection for up to \~40s; if the profile is ready, it will return `200` with the full payload; if not, it will return `202` with an `orderId` and a `Location` header pointing to `GET /orders/{orderId}`.
  * **`405` will be removed from `GET /enhanced` responses.** Clients will no longer need to detect sync vs. async jurisdictions — the contract will be uniform across registries.
  * Initial preview rollout: GB, IE, LU, EE, LV, CN, JP, HK. Slow fulfilment is observed today primarily for Luxembourg, with Hong Kong also in scope.

  <Note>POST + poll is preferred for high-volume pipelines: it avoids server-side connection holds at scale, which accumulate cost when each connection is held for up to \~40s waiting on a slow registry. See the [release note](/company-v2/developer-news/2026-06-async-order-pattern) for full integration guidance.</Note>
</Update>

<Update label="2026-06" tags={["Orders", "Preview"]}>
  🚧 **Preview — not yet available in production.**

  **Typed, versioned order payloads**

  Building on the existing download endpoint (documented below), order results can be retrieved as typed JSON payloads, pinned to a schema version. The JSON payload is the schema of the product you ordered — an Enhanced Profile order returns the `EnhancedProfile` schema, a Beneficial Ownership order returns the `BOProfile` schema — each documented in that product's reference.

  * An optional `_payloadType` field on the response identifies the product payload, so clients can dispatch on it when present.
  * Two new optional fields on `OrderDetails.productDetails`: `productType` (e.g. `BO_PROFILE`, `ENHANCED_PROFILE`) and `schemaVersion`. Both are absent for PDF-only products.
  * `schemaVersion` added to the `POST /v2/orders` request body. Support window: current major (N) and previous (N − 1); older versions return `410`, with `Sunset` (RFC 8594) and `Deprecation` (RFC 9745) headers.

  <Note>`GET /v2/orders/{orderId}` remains metadata-only — fetch the payload from the download endpoint.</Note>
</Update>

<Update label="2026-06" tags={["Orders", "Documentation"]}>
  **Download endpoint now documented**

  `GET /v2/orders/{orderId}/download` is now documented in the API reference. The endpoint takes a `format=json` or `format=pdf` query parameter and returns the order result in the requested format.

  <Note>No change to the API — this endpoint is already available and its behaviour is unchanged; this entry only documents it. (The typed, versioned payloads above are a separate preview.)</Note>
</Update>

<Update label="2026-04" tags={["Enhanced Profile"]}>
  **Profile extensions and address geocoding**

  Enhanced Profile now supports opt-in, per-account extensions that enrich the response with extra data. The first extension, `geocoding`, returns parsed and geocoded address information.

  * Request extensions with the new `extend` query parameter (a comma-separated list) on `GET` Enhanced Profile.
  * `geocoding` adds parsed and geocoded address data via the `additionalInformation` response object.
  * Each `Address` now carries a stable `identifier` that links it to its geocoded entry in `additionalInformation.addressInformation`.
  * New schemas: `AdditionalInformation`, `AddressAdditionalInformation`, `InformationSource`.
  * The mechanism is extensible — further extension types (e.g. firmographics, activity codes) will follow.
  * Unrecognised or unauthorised `extend` values are ignored silently.

  <Note>Opt-in and entitled per account; each extension type carries an additional cost.</Note>
</Update>

<Update label="2026-03" tags={["Enhanced Profile"]}>
  **Typed corporate identifiers**

  Corporate representatives and shareholders can now carry multiple typed identifiers — ACN, ABN, ARBN, ARSN, ARFN, and foreign registration numbers — via a new `otherIdentifiers` array on `CorporationDetails`.

  <Note>Backwards compatible — reuses the existing `Identifier` schema. First surfaced for Australian (ASIC) companies.</Note>
</Update>

<Update label="2026-02" tags={["Enhanced Profile"]}>
  **Shareholding percentage ranges**

  Shareholdings can now express an ownership *range* when a registry does not report an exact percentage.

  * `Shareholding.percentage` is now nullable. When a range applies, `percentage` is null and `percentageIsRange`, `percentageRange`, `percentageLowerLimit`, and `percentageUpperLimit` carry the range.

  <Note>Supports registries such as Estonia (EE) that may report ownership as a range (e.g. "0–100%").</Note>
</Update>

<Update label="2026-02" tags={["Enhanced Profile"]}>
  **Company relationships and registration type**

  Enhanced Profile can now carry company-relationship data and source-registry registration classification.

  * New `companyRelationships` array for relational extract data — subsidiaries, and company evolution (merged, demerged, acquired). Parent / ultimate parent / immediate parent remain in roles and corporate representatives; branches and establishments use a separate establishments model.
  * New `registrationType` and `registrationTypeDetails` capture the foreign registered body and its details at the source registry, where available.

  <Note>`companyRelationships` is in place now for forthcoming relational extract data — do not expect it populated for every entity yet.</Note>
</Update>

<Update label="2026-02" tags={["Enhanced Profile", "Preview"]}>
  **POST Enhanced Profile**

  You can now request an Enhanced Profile with `POST /companies/{kyckrId}/enhanced` — the same resource as `GET`, but it creates an order without holding the connection open.

  <Note>**Preview — coming soon.** Not yet available in production. The full async semantics — `202` fallback on `GET`, the `Location`-header polling shape, and removal of `405` — are documented in the [2026-06 entry](/company-v2/developer-news/2026-06-async-order-pattern).</Note>
</Update>

<Update label="2026-02" tags={["Search"]}>
  **Typed identifiers in Search results**

  Search results now include typed identifiers via an `otherIdentifiers` array with type codes.

  <Note>Available on the single V2 search endpoint. Enables jurisdiction-specific identifier types.</Note>
</Update>

<Update label="2025-10" tags={["Profiles"]}>
  **Field consistency across profiles**

  Profile responses are now more consistent across the V2 API, with shared name components and additional `LiteProfile` and `BasicProfile` fields.

  * New reusable `AlternativeNames` and `PreviousNames` schema components.
  * `previousNames` now uses a standardised structure with proper schema references.
  * `LiteProfile` gains `registrationDate` and `lastAnnualAccountDate`.
  * `BasicProfile` gains `registeredAgentName` and `registeredAgentAddress`.

  <Note>Aligns `LiteProfile` date fields and registered-agent information with V1 and `EnhancedProfile`.</Note>
</Update>

<Update label="2025-07" tags={["Orders"]}>
  **Order response documentation fix**

  Corrected the `Get Order` API response documentation, and documented additional response properties.

  <Note>Planned: previous names on `SearchResults`; Enhanced Profile additions — UBO kind, last annual account date, and registry-sourced voting-rights descriptions.</Note>
</Update>

<Update label="2025-03" tags={["Enhanced Profile"]}>
  **Capital and shareholding simplification**

  Capital and shareholding structures are simplified, and corporate identifiers move to the typed `otherIdentifiers` array.

  * Simplified capital and shareholding structures.
  * `tradingName` is deprecated — use `alias` instead.
  * New `otherIdentifiers` with jurisdiction-specific type codes.

  <Note>`otherIdentifiers` will gain further type codes per jurisdiction over time.</Note>
</Update>

<Update label="2025-02" tags={["Enhanced Profile"]}>
  **Beneficially-held shareholdings**

  Enhanced Profile can now flag beneficially-held shareholdings and classify ambiguous entities.

  * New `capital[].shareholdings[].beneficiallyHeld` field on Enhanced Profile.
  * New "Other" category in the corporations and individuals arrays for entities the registry cannot definitively classify.

  <Note>Introduced ahead of an Australian registry update.</Note>
</Update>

<Update label="2025-02" tags={["Documentation"]}>
  **Documentation corrections**

  Clarified the `ultimateBeneficialOwners` field descriptions on Enhanced Profile.
</Update>

<Update label="2025-01" tags={["Documentation"]}>
  **Documentation corrections**

  Corrected the Enhanced Profile `ultimateBeneficialOwners` documentation.
</Update>

<Update label="2024-11" tags={["UBO Verify", "Preview"]}>
  **Preview feature: UBO Verify**

  UBO Verify launched as a preview feature.

  <Note>**Preview** — limited beta trial; subject to change.</Note>
</Update>