Deprecation

By

The Quable Team

●

Published 2023-09-30

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.

April, 2026 > 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:

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:

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:

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.

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

# 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": [ { ... } ]
    }
}

# 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):

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:

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