---
title: 'OPTIMADE: Universal Materials Data API'
url: https://www.emergentmind.com/topics/open
type: topic
---

# OPTIMADE: Universal Materials Data API

Searching arXiv for the target paper and closely related OPTIMADE materials.
OPTIMADE, the Open Databases Integration for Materials Design consortium’s application programming interface, is a universal API for exchanging materials data across heterogeneous materials databases. It is designed to make materials databases accessible and interoperable through a standardized, RESTful, JSON-based specification, with the first stable release described as specification v1.0. Its stated goals are interoperability, alignment with FAIR data principles, extensibility, and ease of integration for cross-database tools, workflows, and user interfaces [2103.02068].

## 1. Definition and stated objectives

OPTIMADE is a standardized web API specification intended to unify and streamline access to materials databases. The specification is explicitly oriented toward interoperability: a common interface for querying and retrieving materials data from multiple, heterogeneous databases. It is also framed as an implementation of FAIR data principles, promoting data that is Findable, Accessible, Interoperable, and Reusable [2103.02068].

A second central objective is extensibility. The specification allows providers to extend the API for new data types or specific needs within a uniform framework. A third objective is ease of integration, specifically to facilitate the development of cross-database tools, workflows, and user interfaces. In combination, these objectives position OPTIMADE as an interface standard rather than a single database or a single software package [2103.02068].

The first stable release, v1.0, is described as already being supported by many leading databases and several software packages. The paper also states that the advantages of the API are illustrated through worked examples on each of the public materials databases that support the full API specification [2103.02068].

## 2. API architecture and core data model

OPTIMADE follows a RESTful design and uses HTTP(S) as a transport. Requests and responses are formatted in JSON, and the API exposes well-defined endpoints such as `/v1/info` and `/v1/structures`, with clear semantics and required fields [2103.02068].

At the core of the specification is a materials structure resource. Standard attributes listed for this resource include `id`, `chemical_formula_reduced`, `elements`, `cartesian_site_positions`, `lattice_vectors`, and `dimension_types`. The data model is expressed through a common JSON schema, with the stated purpose of enhancing machine-readability and data validation [2103.02068].

The following table summarizes the core structural elements explicitly described for the API.

| Component | Description |
|---|---|
| RESTful design | Based on REST principles and HTTP(S) transport |
| JSON encoding | Requests and responses are formatted in JSON |
| Versioned endpoints | Examples include `/v1/info` and `/v1/structures` |
| Core structure attributes | `id`, `chemical_formula_reduced`, `elements`, `cartesian_site_positions`, `lattice_vectors`, `dimension_types` |

A representative response structure presented in the paper includes `data`, `meta`, and `links` objects, with `meta` containing values such as `query` and `api_version`, and `links` supporting navigation to subsequent result pages. This organization reflects the specification’s emphasis on explicit semantics and machine-oriented consumption [2103.02068].

```json
{
  "data": [
    {
      "type": "structures",
      "id": "mpf_1",
      "attributes": {
        "chemical_formula_reduced": "Al2O3",
        "elements": ["Al", "O"],
        "cartesian_site_positions": [
          [0.47, 0.33, 0.25],
          [0.53, 0.67, 0.75]
        ],
        "lattice_vectors": [
          [5.128, 0.0, 0.0],
          [0.0, 8.831, 0.0],
          [0.0, 0.0, 13.073]
        ],
        "dimension_types": [1, 1, 1]
      }
    }
  ],
  "meta": {"query": "...", "api_version": "1.0"},
  "links": {"next": "..."}
}
```

## 3. Query language, navigation, and extensibility

A notable feature of OPTIMADE is its filtering language, which is defined to support complex queries across databases. The paper gives, as an example:

```text
elements HAS ALL "Al", "O" AND chemical_formula_reduced="Al2O3"
```

This filtering capability is part of the mechanism by which a single client can issue structurally similar requests to multiple compliant providers. The specification also includes pagination for large data sets, which is reflected in response links such as `next`, and explicit versioning of endpoints, for example `/v1/structures` [2103.02068].

Another important aspect is the treatment of extensibility. Providers can add custom attributes prefixed with `_` without breaking clients. This establishes a distinction between the common interoperable core and provider-specific extensions. The data indicate that the specification is intended to support both uniform access and controlled specialization, rather than forcing all providers into a rigidly identical schema [2103.02068].

This combination of filtering, pagination, versioning, and extensible fields defines OPTIMADE not merely as a serialization format, but as a queryable interoperability layer over distributed materials resources.

## 4. Database support and software ecosystem

The paper lists several providers supporting OPTIMADE v1.0: AFLOW, Materials Project, OQMD, NOMAD, Materials Cloud, TCOD, COD, 2DMatPedia, and Open Materials Database [2103.02068].

On the software side, the paper identifies `optimade-python-tools` as a reference server/client and notes integration in ASE and AiiDA. ASE is described as supporting OPTIMADE, while AiiDA is described as a workflow engine with OPTIMADE plugins. These software integrations are presented as enabling advanced data-driven materials science [2103.02068].

| Category | Examples explicitly listed |
|---|---|
| Databases | AFLOW, Materials Project, OQMD, NOMAD, Materials Cloud, TCOD, COD, 2DMatPedia, Open Materials Database |
| Software | `optimade-python-tools`, ASE, AiiDA |

The significance of this support lies in the ability of clients and tools to query any compliant database using the same requests. The paper states that this immediately provides access to diverse resources and crucially reduces the need for custom parsers or scripts [2103.02068]. A plausible implication is that interoperability is achieved not only at the level of data retrieval, but also at the level of workflow design, since the same query and response conventions can be embedded in higher-level software stacks.

## 5. Role in materials data exchange and research practice

The paper identifies several community-level consequences of the specification. OPTIMADE accelerates data discovery by allowing rapid search and comparison of structures or properties from multiple sources. It promotes reproducibility through a well-documented, versioned protocol. It also encourages community standards by establishing a shared vocabulary and API design for data, software tools, and workflows [2103.02068].

Because all materials data are encapsulated under a common JSON schema, the specification emphasizes machine-readability and validation. In practice, this means that clients can rely on standard attributes and endpoint semantics while still navigating heterogeneous provider backends. This suggests a shift from database-specific integration toward protocol-level interoperability.

The FAIR framing is also central. The paper explicitly places OPTIMADE within the effort to make materials data Findable, Accessible, Interoperable, and Reusable. Within materials informatics, this gives the API a role that is infrastructural rather than domain-narrow: it standardizes access mechanisms in a way that supports cross-provider discovery and reuse [2103.02068].

## 6. Challenges, limits, and future directions

The paper identifies several challenges and ongoing efforts. One is schema evolution, particularly the need to handle new data types while maintaining backward compatibility. Another is coverage and adoption, since broader interoperability depends on more providers implementing the standard. A third is federated search, specifically the efficient scaling of queries across many remote providers. A fourth is the exposure of non-structure data, including properties, calculations, or process information, in a standardized way [2103.02068].

Planned improvements listed in the paper include expanding the data model, refining the filter language, and enhancing federated and cross-provider discovery [2103.02068]. These directions indicate that v1.0 is a stable baseline rather than a completed endpoint.

A common misconception is to regard OPTIMADE as equivalent to a single repository or a single canonical schema for all possible materials information. The paper’s description instead emphasizes a common interface, a standard structure resource, and extensible fields for provider-specific additions. The architecture is therefore standardized and open, but not exhaustive. This suggests that the long-term success of the specification depends on balancing a stable interoperable core with enough extensibility to accommodate new materials data types and provider requirements.

Source: https://www.emergentmind.com/topics/open