Recent Deprecations

The Quable Team

●

Published 2026-10-15

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.

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

Scope of this notice

Quable has no visibility into the technical implementation of integrations built by customers, their internal developers, or third-party integrators. With the exception of QuableApps developed and maintained directly by Quable, Quable is therefore unable to confirm, deny, or assess whether a given API, endpoint, or data format is used by a customer's integrations, or what impact a deprecation may have on them.

It remains the customer's responsibility to identify which Quable APIs their integrations rely on and to consult their developer or integrator ahead of each deprecation date to assess and manage any potential impact.

October, 2026 > April 15, 2027

Deprecation Date: October, 2026
Removal Date: April 15, 2027

Removal of static API tokens

Quable PIM currently exposes 2 static API tokens:

To improve security, these static tokens are being removed. You can now generate your own API tokens directly in Quable PIM (see the API tokens documentation — French version).

Starting April 15th, 2027, only the tokens you have generated will be accepted.

Impacted endpoints

All API endpoints

Migration guide

Generate a new API token in Quable PIM (see documentation above).
Replace the static token with your new token in all your integrations.

The way the token is sent does not change:

curl --request GET 'https://{{instance}}.quable.com/api/{endpoint}' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer {your_generated_token}'

Removal of the `isProtected` field from key-values

The isProtected field is deprecated and will be removed from key-values on April 15th, 2027.

Once removed, only administrators will be able to create, update or delete a key-value. The isProtected field therefore becomes useless and obsolete.

Impacted endpoints

GET /api/keyvalues
GET /api/keyvalues/:id
POST /api/keyvalues
PUT /api/keyvalues/:id
POST /api_1.php/settings
POST /api_1.php/settings/:key
PUT /api_1.php/settings/:key

Migration guide

Read a key-value

The current response contains the isProtected field:

curl --request GET 'https://{{instance}}.quable.com/api/keyvalues/my_config_key' \
--header 'Accept: application/json'

{
    "id": "my_config_key",
    "value": "value",
    "isProtected": true,
    "isPublic": false
}

After April 15th, 2027, the isProtected field will no longer be present in the response:

curl --request GET 'https://{{instance}}.quable.com/api/keyvalues/my_config_key' \
--header 'Accept: application/json'

{
    "id": "my_config_key",
    "value": "value",
    "isPublic": false
}

Create or update a key-value

The current payload accepts the isProtected field:

curl --request POST 'https://{{instance}}.quable.com/api/keyvalues' \
--header 'Content-Type: application/json' \
--data-raw '{
    "id": "my_config_key",
    "value": "value",
    "isProtected": true,
    "isPublic": false
}'

After April 15th, 2027, the isProtected field is no longer needed. If it is still sent, it will be ignored. You can safely remove it from your payloads:

curl --request POST 'https://{{instance}}.quable.com/api/keyvalues' \
--header 'Content-Type: application/json' \
--data-raw '{
    "id": "my_config_key",
    "value": "value",
    "isPublic": false
}'

Document type code can no longer be updated

Starting April 15th, 2027, it will no longer be possible to update the code of a document type.

When a document type is created, its code is used to generate its default name attribute, in the form <document_type_code>_name. Every document created with this document type stores its name in this attribute, which can then be used in search filters, exports, automatic links, etc.

Updating the code of a document type is therefore not harmless: the expected name attribute code changes, but the name values already stored on existing documents are not updated accordingly. This can cause malfunctions in the application and in your integrations, such as products displayed without a name.

For example, when only the letter case of the code changed, API v5 mitigates the issue by returning the name field in lowercase. However, integrations that still expect the original casing may fail to match it.

To preserve the integrity of data models, and as is already the case for other entities (workflow, completeness, link type...), the code of a document type will become immutable.

Impacted endpoints

PUT /api_1.php/document_types/:id

Migration guide

Current behavior — the request succeeds and the document type code is updated:

curl --request PUT 'https://{{instance}}.quable.com/api_1.php/document_types/{document_type_id}' \
--header 'Content-Type: application/json' \
--data-raw '{
    "code": "new_code"
}'

# HTTP 201 — the document type code is updated

Future behavior — sending a different code will be rejected:

curl --request PUT 'https://{{instance}}.quable.com/api_1.php/document_types/{document_type_id}' \
--header 'Content-Type: application/json' \
--data-raw '{
    "code": "new_code"
}'

# HTTP 400 — the document type code cannot be updated

If the code is sent but unchanged, the request will still succeed. You do not need to remove it from your update payloads:

curl --request PUT 'https://{{instance}}.quable.com/api_1.php/document_types/{document_type_id}' \
--header 'Content-Type: application/json' \
--data-raw '{
    "code": "same_code"
}'

# HTTP 200

Empty single-select attributes will return `null` instead of an empty array

There are two types of predefined-value selection attributes: single-select and multi-select.
As their names suggest, a single-select attribute can only hold one value, whereas a multi-select attribute can hold several.

Today, when no value is set, both types return an empty array [], which is inconsistent for a single-select attribute.

Starting April 15th, 2027, a single-select attribute with no value will return null. This may impact third-party integrations.

Impacted endpoints

GET /api/documents
GET /api/documents/:id

Migration guide

Current behavior — an empty single-select attribute returns an empty array:

curl --request GET 'https://{{instance}}.quable.com/api/documents/{document_code}' \
--header 'Accept: application/json'

{
    "attributes": {
        "simple_select_with_value": [
            {
                "id": "predefined_value_id",
                "labels": {
                    "en_GB": "english label",
                    "fr_FR": "french label"
                }
            }
        ],
        "simple_select_without_value": []
    }
}

Future behavior — an empty single-select attribute will return null:

curl --request GET 'https://{{instance}}.quable.com/api/documents/{document_code}' \
--header 'Accept: application/json'

{
    "attributes": {
        "simple_select_with_value": [
            {
                "id": "predefined_value_id",
                "labels": {
                    "en_GB": "english label",
                    "fr_FR": "french label"
                }
            }
        ],
        "simple_select_without_value": null
    }
}

Single-select attributes that have a value are not affected.

Preview the new format now

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

curl --request GET 'https://{{instance}}.quable.com/api/documents/{document_code}' \
--header 'Accept: application/json' \
--header 'X-Quable-Deprecation: april-27'

{
    "attributes": {
        "simple_select_with_value": [ { ... } ],
        "simple_select_without_value": null
    }
}

Past deprecations

Looking for older deprecation notices? Browse the Archived Deprecations section.

Recent Deprecations

Deprecation calendar

October, 2026 > April 15, 2027

Removal of static API tokens

Impacted endpoints

Migration guide

Removal of the isProtected field from key-values

Impacted endpoints

Migration guide

Document type code can no longer be updated

Impacted endpoints

Migration guide

Empty single-select attributes will return null instead of an empty array

Impacted endpoints

Migration guide

Preview the new format now

Past deprecations

Removal of the `isProtected` field from key-values

Empty single-select attributes will return `null` instead of an empty array