Usage Policy

Rate Limiting

Info

Rate limits are applied per client based on IP address to ensure fair usage and system stability. Limits are tiered by endpoint type — collection endpoints allow higher throughput to support harvesting, while aggregation endpoints are more restricted due to query complexity.

Limits

Endpoint type	Endpoints	Request limit	Time window
Single records	`/id/object/`, `/id/agent/`, `/id/exhibition/`, `/id/concept/`	120	per minute
Collections	`/id/objects`, `/id/agents`, `/id/exhibitions`, `/id/concepts`	300	per minute
Aggregations	`/id/colors`, `/id/types`	20	per minute
Private stream	`/id/private/`	600	per minute
v1 (deprecated)	all v1 endpoints	120	per minute

Response headers

When making requests the following headers are included to help track your rate limit status:

Header	Description	Example
`RateLimit-Limit`	Maximum requests allowed per time window	`300`
`RateLimit-Remaining`	Requests remaining in the current window	`247`
`RateLimit-Reset`	Seconds until the rate limit resets	`42`

Rate limit exceeded

When you exceed the rate limit the API responds with HTTP 429:

{
    "status": 429,
    "error": "Too many requests. Please slow down."
}

Wait until the window resets before retrying. Implement exponential backoff in your client to avoid repeated 429 responses.

Harvesting the full collection

The collection endpoints allow up to 300 requests per minute — enough to paginate the full object collection at itemsPerPage=50 in under a minute. To stay well within limits, a 250ms delay between pages is sufficient:

async function harvest(url) {
    const data = await fetch(url).then(r => r.json())
    // process data["hydra:member"]
    if (data["hydra:view"]["hydra:next"]) {
        await new Promise(r => setTimeout(r, 250))
        await harvest(data["hydra:view"]["hydra:next"])
    }
}

API stability & versioning contract

We are committed to maintaining a stable, predictable API that developers and institutions can depend on. The following principles govern how we manage change.

Versioning

The API uses URI-based versioning (/v1/, /v2/). Each version is an independent, stable contract. Breaking changes always result in a new version — existing versions are never modified in a breaking way.

Version	Status	Sunset date
v1	⚠️ Deprecated	31 December 2026
v2	✅ Current	—

What counts as a breaking change

The following changes will always result in a new version:

Removing or renaming a field
Changing the type or structure of a field
Changing a URI pattern
Removing an endpoint

The following changes may happen within an existing version without a new version:

Adding new optional fields
Adding new endpoints
Bug fixes that make the response more correct

Deprecation policy

When a version is deprecated:

A minimum notice period of 6 months is given before sunset
The deprecation is announced in the documentation, in response headers (Deprecation, Sunset, Link) and in the GitHub changelog
The deprecated version remains fully functional until the sunset date

Response headers on deprecated endpoints

All v1 responses include the following headers:

Deprecation: true
Sunset: Wed, 31 Dec 2026 23:59:59 GMT
Link: <https://data.designmuseumgent.be/v2/>; rel="successor-version"

Stable URIs

All resource URIs are persistent and compliant with the Flemish URI standard. A URI such as:

https://data.designmuseumgent.be/v2/id/object/1987-1105

will always resolve to the same object. URIs are never reused for different resources.

`Link` header

All collection responses include a Link header following RFC 8288 with pagination relations:

Link: <...?page=1>; rel="first",
      <...?page=843>; rel="last",
      <...?page=2>; rel="next"

Relation	Description
`first`	First page
`last`	Last page
`next`	Next page (omitted on last page)
`prev`	Previous page (omitted on first page)

This mirrors the hydra:view pagination in the response body and allows clients to paginate without parsing the JSON-LD body.

Changelog

All changes are documented in the GitHub changelog and in GitHub releases. Each release follows semantic versioning: major.minor.patch.

Digital reproductions — re-use

Although we encourage re-use and creative applications using our collection data, we also want to ensure that the rights of the designers, artists and researchers to whom any intellectual property might belong are safeguarded.

Attribution

As a minimum, when making use of our digital reproductions we ask you to mention:

the designer or maker of the work
the applicable license

We also encourage you to include:

the title of the work
the year of the work
a reference to the museum: "collection Design Museum Gent"

Licenses

Please respect the limitations and usage policy as defined by the given license:

License	Description
Public Domain	This object belongs to the Public Domain and is free to use. We nonetheless encourage fair attribution practice as described above.
CC BY-NC-ND 4.0	You are free to copy and redistribute the material in any medium or format. You must give appropriate credit, provide a link to the license, and indicate if changes were made. The material may not be used for commercial purposes. Modified material may not be redistributed.
In Copyright	The work is still under copyright. Reuse is not permitted unless agreed with the copyright holder.

Warning

Always check the license field in the API response before publishing or redistributing any digital reproduction.

Wikipedia content — re-use

Agent records may include biographical texts and titles sourced from Wikipedia via the Wikipedia API.

Attribution

All Wikipedia-sourced content is licensed under CC BY-SA 4.0. When displaying this content you must:

attribute the text to Wikipedia
include a link to the source page (available in crm:P67_refers_to)
include a link to the license: https://creativecommons.org/licenses/by-sa/4.0/

Support & contact

Info

Need help or have questions about permitted use?

Development and coordination by Olivier Van D'huynslager