--- title: "Get a cell specification with nested component and material data" method: GET path: "/cell_specifications/{cell_spec_id}" tags: ["Cell Specifications"] --- # Get a cell specification with nested component and material data `GET /cell_specifications/{cell_spec_id}` ## Request - Base URL: `https://api.ionworks.com` - URL: `https://api.ionworks.com/cell_specifications/{cell_spec_id}` - Auth: none declared Retrieve a cell specification with nested component and material information. Returns the specification with anode, cathode, electrolyte, separator, and case components, each including their material details. ## Path parameters - `cell_spec_id` string, uuid, required ## Response `200` Successful Response - CellSpecificationWithComponentsWithLinks - `url` string, nullable - `api_url` string, nullable - `name` string, required: Name of the cell specification - `form_factor` string, nullable: Physical form factor. Common values: '18650', '21700', 'R2032' (coin cell), 'pouch', 'prismatic', 'cylindrical'. - `manufacturer` string, nullable: Who assembled/manufactured the cell - `ratings` Ratings, required: Electrical ratings from spec sheet / design targets. - `capacity` Quantity, required: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `voltage_min` Quantity, required: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `voltage_max` Quantity, required: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `nominal_voltage` Quantity: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `energy` Quantity: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `energy_density_gravimetric` Quantity: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `energy_density_volumetric` Quantity: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `max_discharge_rate` Quantity: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `max_charge_rate` Quantity: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `charge_temperature_min` Quantity: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `charge_temperature_max` Quantity: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `discharge_temperature_min` Quantity: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `discharge_temperature_max` Quantity: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `max_pulse_discharge_current` Quantity: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `max_pulse_discharge_duration` Quantity: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `standard_charge_current` Quantity: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `charge_cutoff_current` Quantity: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `acir_1khz` Quantity: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `dcir` Quantity: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `dcir_pulse_duration` Quantity: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `dcir_soc` Quantity: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `cycle_life` integer, nullable: Rated cycle life: cycles until capacity reaches cycle_life_end_of_life, e.g., 500 - `cycle_life_end_of_life` Quantity: A numeric value with its physical unit. All numeric fields that carry physical meaning across the cell-data API (capacities, voltages, masses, temperatures, etc.) use this structured format rather than bare floats. That keeps the units on the wire so the server, clients, and downstream consumers cannot disagree about them. Canonical form: ```json {"value": 1.1, "unit": "A.h"} ``` Common units used across the platform: ``V``, ``A``, ``A.h``, ``W.h``, ``degC``, ``s``, ``ohm``, ``mm``, ``g``, ``mg.cm-2``, ``C`` (C-rate). Units are stored in PyBaMM notation: ``.``-separated atoms with signed integer exponents and no ``*``/``/`` (``mg.cm-2``, ``A.h``, ``W.h.kg-1``). Pint-style strings (``mg/cm**2``, ``A*h``, ``W*h/kg``) are still accepted on input for backwards compatibility and are normalized to PyBaMM notation on construction. Either form parses correctly via :meth:`to_pint`. - `value` union, required - number - integer - `unit` string, required: Unit string in PyBaMM notation: '.'-separated atoms with signed integer exponents (e.g. 'A.h', 'mg.cm-2', 'W.h.kg-1'). Pint-style strings ('A*h', 'mg/cm**2') are also accepted and normalized to PyBaMM notation. Common units: V, A, A.h, W.h, degC, s, ohm. - `anode_id` string, nullable: ID of the anode component - `cathode_id` string, nullable: ID of the cathode component - `electrolyte_id` string, nullable: ID of the electrolyte component - `separator_id` string, nullable: ID of the separator component - `case_id` string, nullable: ID of the case component - `properties` object, nullable: Other design-level properties that are not electrical ratings and not tied to a specific component — e.g. assembly method, overall cell dimensions, mass, target thickness. Numeric values must use the Quantity format ({'value': ..., 'unit': ...}). - `source` object, nullable: Provenance of the design. Typical keys: 'doi', 'citation', 'publication_date' (ISO 8601), 'license', 'creator_name', 'creator_orcid'. Lives on the specification (not the instance) because it describes the published design. - `notes` string, nullable: Free-text notes about the cell specification - `id` string, required: Unique identifier for the cell specification - `organization_id` string, required: Organization ID of the cell specification - `project_id` string, required: Project this cell specification belongs to - `created_at` string, date-time, nullable: When this specification was created - `updated_at` string, date-time, nullable: When this specification was last modified - `created_by` string, nullable: User ID of the user who created this specification - `created_by_email` string, nullable: Email of the user who created this specification - `instance_ids` object[], nullable: List of instance IDs associated with the cell specification - `default_parameterized_model_id` string, nullable: ID of the parameterized model marked as this specification's default model, or None if unset. - `cad_file_path` string, nullable: Storage path of the attached CAD model, if any. - `cad_file_name` string, nullable: Original filename of the attached CAD model. - `cad_thumbnail_path` string, nullable: Storage path of the rendered CAD thumbnail; None when no model is attached or the model could not be rendered. - `cad_thumbnail_url` string, nullable: Signed URL of the CAD thumbnail. Only set on list responses that pass include=thumbnail_url. - `anode` CellComponentWithMaterial: Cell component with nested material information. - `component_type` 'cathode' | 'anode' | 'electrolyte' | 'separator' | 'case' | 'cell', required: Enum for cell component types. - `material_id` string, required: ID of the material - `properties` object, nullable: Application properties using Quantity format for numerics. Example: {'diameter': {'value': 14, 'unit': 'mm'}, 'binder': 'PVDF'} - `id` string, required: Unique identifier for the component - `organization_id` string, required: Organization ID of the component - `project_id` string, required: Project the component is scoped to, derived from the cell specification(s) that reference it. - `created_at` string, date-time, required: Timestamp when the component was created - `updated_at` string, date-time, required: Timestamp when the component was last updated - `created_by` string, nullable: User ID of the creator. - `material` Material: Model representing a material as returned by the API. - `name` string, required: Name of the material - `definition` object, nullable: Material definition (formula, type, constituents) - `manufacturer` string, nullable: Manufacturer of the material - `product_id` string, nullable: Supplier product ID - `id` string, required: Unique identifier for the material - `organization_id` string, required: Organization ID of the material - `project_id` string, required: Project the material is scoped to, derived from the cell specification(s) that reference it. - `created_at` string, date-time, required: Timestamp when the material was created - `updated_at` string, date-time, required: Timestamp when the material was last updated - `created_by` string, nullable: User ID of the creator. - `created_by_email` string, nullable: Email of the creator, flattened from the ``users`` join. None for materials created before the column existed, or by a service account. - `property_count` integer: Number of property datasets attached to this material - `cathode` CellComponentWithMaterial: Cell component with nested material information. - `component_type` 'cathode' | 'anode' | 'electrolyte' | 'separator' | 'case' | 'cell', required: Enum for cell component types. - `material_id` string, required: ID of the material - `properties` object, nullable: Application properties using Quantity format for numerics. Example: {'diameter': {'value': 14, 'unit': 'mm'}, 'binder': 'PVDF'} - `id` string, required: Unique identifier for the component - `organization_id` string, required: Organization ID of the component - `project_id` string, required: Project the component is scoped to, derived from the cell specification(s) that reference it. - `created_at` string, date-time, required: Timestamp when the component was created - `updated_at` string, date-time, required: Timestamp when the component was last updated - `created_by` string, nullable: User ID of the creator. - `material` Material: Model representing a material as returned by the API. - `name` string, required: Name of the material - `definition` object, nullable: Material definition (formula, type, constituents) - `manufacturer` string, nullable: Manufacturer of the material - `product_id` string, nullable: Supplier product ID - `id` string, required: Unique identifier for the material - `organization_id` string, required: Organization ID of the material - `project_id` string, required: Project the material is scoped to, derived from the cell specification(s) that reference it. - `created_at` string, date-time, required: Timestamp when the material was created - `updated_at` string, date-time, required: Timestamp when the material was last updated - `created_by` string, nullable: User ID of the creator. - `created_by_email` string, nullable: Email of the creator, flattened from the ``users`` join. None for materials created before the column existed, or by a service account. - `property_count` integer: Number of property datasets attached to this material - `electrolyte` CellComponentWithMaterial: Cell component with nested material information. - `component_type` 'cathode' | 'anode' | 'electrolyte' | 'separator' | 'case' | 'cell', required: Enum for cell component types. - `material_id` string, required: ID of the material - `properties` object, nullable: Application properties using Quantity format for numerics. Example: {'diameter': {'value': 14, 'unit': 'mm'}, 'binder': 'PVDF'} - `id` string, required: Unique identifier for the component - `organization_id` string, required: Organization ID of the component - `project_id` string, required: Project the component is scoped to, derived from the cell specification(s) that reference it. - `created_at` string, date-time, required: Timestamp when the component was created - `updated_at` string, date-time, required: Timestamp when the component was last updated - `created_by` string, nullable: User ID of the creator. - `material` Material: Model representing a material as returned by the API. - `name` string, required: Name of the material - `definition` object, nullable: Material definition (formula, type, constituents) - `manufacturer` string, nullable: Manufacturer of the material - `product_id` string, nullable: Supplier product ID - `id` string, required: Unique identifier for the material - `organization_id` string, required: Organization ID of the material - `project_id` string, required: Project the material is scoped to, derived from the cell specification(s) that reference it. - `created_at` string, date-time, required: Timestamp when the material was created - `updated_at` string, date-time, required: Timestamp when the material was last updated - `created_by` string, nullable: User ID of the creator. - `created_by_email` string, nullable: Email of the creator, flattened from the ``users`` join. None for materials created before the column existed, or by a service account. - `property_count` integer: Number of property datasets attached to this material - `separator` CellComponentWithMaterial: Cell component with nested material information. - `component_type` 'cathode' | 'anode' | 'electrolyte' | 'separator' | 'case' | 'cell', required: Enum for cell component types. - `material_id` string, required: ID of the material - `properties` object, nullable: Application properties using Quantity format for numerics. Example: {'diameter': {'value': 14, 'unit': 'mm'}, 'binder': 'PVDF'} - `id` string, required: Unique identifier for the component - `organization_id` string, required: Organization ID of the component - `project_id` string, required: Project the component is scoped to, derived from the cell specification(s) that reference it. - `created_at` string, date-time, required: Timestamp when the component was created - `updated_at` string, date-time, required: Timestamp when the component was last updated - `created_by` string, nullable: User ID of the creator. - `material` Material: Model representing a material as returned by the API. - `name` string, required: Name of the material - `definition` object, nullable: Material definition (formula, type, constituents) - `manufacturer` string, nullable: Manufacturer of the material - `product_id` string, nullable: Supplier product ID - `id` string, required: Unique identifier for the material - `organization_id` string, required: Organization ID of the material - `project_id` string, required: Project the material is scoped to, derived from the cell specification(s) that reference it. - `created_at` string, date-time, required: Timestamp when the material was created - `updated_at` string, date-time, required: Timestamp when the material was last updated - `created_by` string, nullable: User ID of the creator. - `created_by_email` string, nullable: Email of the creator, flattened from the ``users`` join. None for materials created before the column existed, or by a service account. - `property_count` integer: Number of property datasets attached to this material - `case` CellComponentWithMaterial: Cell component with nested material information. - `component_type` 'cathode' | 'anode' | 'electrolyte' | 'separator' | 'case' | 'cell', required: Enum for cell component types. - `material_id` string, required: ID of the material - `properties` object, nullable: Application properties using Quantity format for numerics. Example: {'diameter': {'value': 14, 'unit': 'mm'}, 'binder': 'PVDF'} - `id` string, required: Unique identifier for the component - `organization_id` string, required: Organization ID of the component - `project_id` string, required: Project the component is scoped to, derived from the cell specification(s) that reference it. - `created_at` string, date-time, required: Timestamp when the component was created - `updated_at` string, date-time, required: Timestamp when the component was last updated - `created_by` string, nullable: User ID of the creator. - `material` Material: Model representing a material as returned by the API. - `name` string, required: Name of the material - `definition` object, nullable: Material definition (formula, type, constituents) - `manufacturer` string, nullable: Manufacturer of the material - `product_id` string, nullable: Supplier product ID - `id` string, required: Unique identifier for the material - `organization_id` string, required: Organization ID of the material - `project_id` string, required: Project the material is scoped to, derived from the cell specification(s) that reference it. - `created_at` string, date-time, required: Timestamp when the material was created - `updated_at` string, date-time, required: Timestamp when the material was last updated - `created_by` string, nullable: User ID of the creator. - `created_by_email` string, nullable: Email of the creator, flattened from the ``users`` join. None for materials created before the column existed, or by a service account. - `property_count` integer: Number of property datasets attached to this material ## Other responses - `422`: Validation Error ## Changes - **2026-10-28** `3abf50e2d741`: 2 info - added the optional property `api_url` to the response with the `200` status - added the optional property `url` to the response with the `200` status - **2026-10-06** `6fbec094b30e`: 14 info - added the optional property `ratings/acir_1khz` to the response with the `200` status - added the optional property `ratings/charge_cutoff_current` to the response with the `200` status - added the optional property `ratings/charge_temperature_max` to the response with the `200` status - added the optional property `ratings/charge_temperature_min` to the response with the `200` status - …10 more - **2026-10-04** `1f50d4b61910`: 4 info - added the optional property `cad_file_name` to the response with the `200` status - added the optional property `cad_file_path` to the response with the `200` status - added the optional property `cad_thumbnail_path` to the response with the `200` status - added the optional property `cad_thumbnail_url` to the response with the `200` status - **2026-09-30** `ea3d377fec1a`: 1 breaking - for the `path` request parameter `cell_spec_id`, the format changed from no format to `uuid` - …earlier changes not shown [Operation history](https://skmtc.dev/ionworks/apis/ionworks-api/changes/cell_specifications/:cell_spec_id/get.md) --- [API](https://skmtc.dev/ionworks/apis/ionworks-api.md) - [All operations](https://skmtc.dev/ionworks/apis/ionworks-api/llms.txt) - [OpenAPI document](https://skmtc.dev/ionworks/apis/ionworks-api/revisions/abebbbc5f60a?raw)