## Deprecation calendar 

In the continuous evolution of our SaaS solution, we perform a review/update of our product (mostly on API or technical stuff) every six months.
This review results in some endpoints, attributes, or operations being deprecated/removed.
The deprecations are announced **six months in advance** of their removal date, to give you time to verify that you're not impacted by them or to migrate your code accordingly.

!!!primary
Announcements and deprecations take place around October 15th and April 15th every year.
!!!

---

### April, 2026 > October 15, 2026

!!!danger
Deprecation Date: April, 2026
Removal Date: October 15, 2026
!!!

#### Removal of field `documentTypeCode` in favor of `documentType.id`

The `documentTypeCode` field is deprecated and will be removed on October 15th, 2026. It has been superseded by the `documentType.id` field, which carries the same value within the existing `documentType` object.

The motivation behind this change is to standardize our APIs.

##### Impacted endpoints

- `GET /api/attributes`
- `POST /api/attributes`
- `GET /api/attributes/:id`
- `PUT /api/attributes/:id`
- `GET /api/attributes-sets`
- `POST /api/attributes-sets`
- `GET /api/attributes-sets/:id`
- `PUT /api/attributes-sets/:id`
- `GET /api/completeness-settings`
- `POST /api/completeness-settings`
- `GET /api/completeness-settings/:id`
- `PUT /api/completeness-settings/:id`

##### Migration guide

The current API response contains both fields:

```json
curl --request GET 'https://{{instance}}.quable.com/api/attributes/{id}'

{
  "documentTypeCode": "quable_article",
  "documentType": {
    "id": "quable_article"
  }
}
```

After October 15th, 2026, the `documentTypeCode` field will no longer be present. Use `documentType.id` instead.

---

#### Changes in `application/json` format for several endpoints

We detected inconsistencies on 3 API endpoints when using the `application/json` format. The response included additional keys that serve no purpose and make those responses non-standard compared to other endpoints.

The motivation behind this change is to standardize our APIs.

**Current behavior** — response is a JSON object keyed by `legacyId`:

```json
curl --request GET 'https://{{instance}}.quable.com/api/documents'
--header 'Content-Type: application/json'

{
  "42": {
    "@id": "/documents/alice",
    "id": "alice",
    "legacyId": "42",
    "attributes": { ... }
  }
}
```

**Future behavior** — response will be a JSON array:

```json
curl --request GET 'https://{{instance}}.quable.com/api/documents'
--header 'Content-Type: application/json'

[
  {
    "@id": "/documents/alice",
    "id": "alice",
    "legacyId": "42",
    "attributes": { ... }
  }
]
```

##### Impacted endpoints

- `GET /api/documents`
- `GET /api/variants`
- `GET /api/assets`

##### Preview the new format now

You can preview the future response format by adding the `X-Quable-Deprecation: oct-26` header to your requests. After the deprecation period, this header will have no effect.

```bash
curl --request GET 'https://{{instance}}.quable.com/api/documents' \
--header 'Accept: application/json' \
--header 'X-Quable-Deprecation: oct-26'

[
  {
    "@id": "/documents/alice",
    "id": "alice",
    "legacyId": "42",
    "attributes": { ... }
  }
]
```

---

#### Removal of `application/hal+json` format for content negotiation

The `application/hal+json` content type is being removed in favor of `application/ld+json`. Both formats are redundant and we want to focus on formats that are well supported by our team.

- If you do **not** provide an `Accept` header, the default content type remains `application/ld+json` — no action needed.
- If you use `Accept: application/hal+json`, you must migrate to `Accept: application/ld+json`. The data structure differs, so code adaptation is required.

##### Migration guide

```bash
# Before
curl --request GET "https://{{instance}}.quable.com/api/documents?page=1&limit=2" \
--header 'Accept: application/hal+json'

{
    "_links": {
        "self": { "href": "/api/documents?limit=2&page=1" },
        "first": { "href": "/api/documents?limit=2&page=1" },
        "last": { "href": "/api/documents?limit=2&page=35" },
        "next": { "href": "/api/documents?limit=2&page=2" },
        "item": [
            { "href": "/api/documents/0123456789" },
            { "href": "/api/documents/020714858735" }
        ]
    },
    "totalItems": 70,
    "itemsPerPage": 2,
    "_embedded": {
        "item": [ { ... } ]
    }
}
```

```bash
# After
curl --request GET "https://{{instance}}.quable.com/api/documents?page=1&limit=2" \
--header 'Accept: application/ld+json'

{
    "@context": "/api/contexts/Document",
    "@id": "/api/documents",
    "@type": "hydra:Collection",
    "hydra:totalItems": 70,
    "hydra:member": [ { ... } ],
    "hydra:view": {
        "@id": "/api/documents?limit=2&page=1",
        "@type": "hydra:PartialCollectionView",
        "hydra:first": "/api/documents?limit=2&page=1",
        "hydra:last": "/api/documents?limit=2&page=35",
        "hydra:next": "/api/documents?limit=2&page=2"
    },
    "hydra:search": { ... }
}
```

---

#### Removing sign-in with credentials in query string

To reinforce security, credentials will no longer be accepted as query string parameters on `POST /api_1.php/sessions`.

**Current (deprecated):**

```bash
curl --request POST "https://{{instance}}.quable.com/api_1.php/sessions?signin[username]=my-username&signin[password]=my-password"
```

##### Migration guide

Provide credentials as `form/data` or `application/json` instead:

```bash
curl --request POST 'https://{{instance}}.quable.com/api_1.php/sessions' \
--form 'signin[username]="my-username"' \
--form 'signin[password]="mypassword"'

# or

curl --request POST 'https://{{instance}}.quable.com/api_1.php/sessions' \
--header 'Content-Type: application/json' \
--data-raw '{
    "signin": {
        "username": "my-username",
        "password": "my-password"
    }
}'
```

---

## Past deprecations

Looking for older deprecation notices? Browse the [Archived Deprecations](/archive-deprecations/) section.