A connected artwork depends on organisations and systems it does not control: provider, domain, certificate, API, account, tariff, network and response format. That it works during assembly does not guarantee that it will work throughout the exhibition.
If the artwork is going out on loan, also see How to lend a digital or technology-based artwork for an exhibition.
Dependency map
Draw the path from the interaction to the response. For each service, record the provider, endpoint, version, account, authentication, data, limits, cost, jurisdiction, artistic dependency and alternative.
The Guggenheim acquisition checklist for web artwork asks for a written list of the web services and external APIs the artwork uses, another of its external server calls, external links and web scraping, the requirements and dependencies, copies of the libraries and the installation instructions.
Decide which dependency is constitutive
A specific API may be the subject and material of the artwork, or only a means of obtaining data. If it is a constitutive dependency, replacing it may reinterpret the piece. If it is a functional dependency, an equivalent source may be accepted. Put it in writing.
Test the venue’s network
Check bandwidth, latency, DNS, firewall, proxy, Wi-Fi, permitted addresses, certificates, ports and isolation. Do not rely on a guest network as your only plan.
Cache and local copy
A cache reduces calls and allows brief continuity. Record duration, date, content, refresh and rights. Do not turn live data into recorded data without explaining the change.
Where lawful, keep reference responses, the data schema and a local simulator. Rhizome offers servers and encapsulated environments running old versions of ColdFusion, PHP or Ruby for internet art from roughly 1996 to 2010, and maintains those environments rather than rewriting the code for current software. Tate’s project on software-based art documents dependencies, disk images and emulation; its page does not address networks or external services.
Degraded mode
Define states:
- normal;
- slow;
- delayed data;
- API unavailable;
- no internet;
- provider closed.
For each one, decide whether to show the cache, a message, a simulation or documentation, or to stop the artwork. The public must not mistake a silent failure for the artwork’s behaviour.
API versions and changes
Pin the version and expected fields. Validate responses and log errors. Monitor deprecation notices. The Met announced on 4 September 2026 that the /v1/search endpoint of its collection API would be retired on 1 October 2026 and recommended migrating to /v1.1/search. It is an example of a dependency that calls for documented migration.
Accounts, keys and costs
Use an institutional or dedicated account, least privilege, key rotation and separate secret storage. Define who pays, plus limits, alerts and renewal. Do not embed keys in the repository or in a public browser.
Network and system security
Isolate old services, apply least privilege, log access and avoid automatic updates during the exhibition without prior testing. A historical artwork may require encapsulation rather than a direct connection.
Data protection
If the artwork sends personal data to a provider, identify the controller, the processor and the purposes. Article 28 of the GDPR allows the controller to use only processors that provide sufficient guarantees and requires that processing be governed by a binding contract or other binding legal act. Articles 44 et seq. set conditions for transferring data to a third country or an international organisation; the AEPD summarises them for international transfers outside the European Economic Area.
See the guide on artworks that collect data. Do not call data “anonymous” if identifiers, voice, image or combinations make identification possible.
Monitoring
Log availability, latency, errors, quota and changes in responses without collecting more data from the public. Define who receives alerts and who may intervene.
If the service shuts down
Keep the contract, documentation, schema, permitted responses, code, interface, screenshots and recordings. Decide with the artist whether to stop, migrate, emulate or reinterpret. To prepare the code, see How to prepare creative code so that it can run again.
Checklist
- Dependencies, accounts, versions and costs inventoried.
- It has been decided which service is constitutive.
- The venue’s real network has been tested.
- Cache, simulation and degraded mode are authorised.
- Responses and versions are validated.
- Secrets and accounts have an owner.
- Monitoring is in place without excessive surveillance.
- GDPR, processors and transfers have been reviewed.
- A documented plan exists for shutdown or change.
Further reading
- How to lend a digital or technology-based artwork for an exhibition.
- How to prepare creative code so that it can run again.
- If your artwork collects data from the public.
Sources
- Guggenheim, acquisition checklist for web artwork. The document shows no date or version and does not name the institution in its text; attribution is based on the domain where it is hosted.
- Rhizome, preservation services. Legacy environments and servers; the page is a service offering with its own pricing.
- Tate, software-based art preservation. Project initiated in October 2017; it does not address external services or networks.
- The Metropolitan Museum of Art, Open Access API. Notice dated 4 September 2026 about the retirement of
/v1/searchon 1 October 2026; it has not been verified that the retirement took place. - Regulation (EU) 2016/679 (GDPR), official text. Articles 28 and 44 et seq.
- AEPD, guarantees for international transfers of personal data. Last modified: 19 June 2026.
Status: Verified. Review: 11 October 2026. General information on documentation practices; it is not security or data protection advice. If you find an error, write to me.