---
title: "Get detailed information for a cell measurement"
method: GET
path: "/cell_measurements/{measurement_id}/detail"
tags: ["Cell Measurements"]
deprecated: true
---

# Get detailed information for a cell measurement

`GET /cell_measurements/{measurement_id}/detail`

## Request

- Base URL: `https://api.ionworks.com`
- URL: `https://api.ionworks.com/cell_measurements/{measurement_id}/detail`
- Auth: none declared

> **Deprecated.**

Retrieves detailed information for a specific cell
measurement by measurement ID.

**Deprecated**: prefer the individual endpoints
GET /steps, GET /cycles, POST /series/query, and
GET /steps_and_cycles instead.

Supports zoom-based resampling: specify x_min, x_max,
and x_column to fetch higher resolution data for a
specific x-axis range.

## Path parameters

- `measurement_id` string, uuid, required

## Query parameters

- `target_rows` integer, nullable: Target rows for downsampled time series
- `columns` string, nullable: Comma-separated list of columns to load (e.g., 'time,voltage')
- `step_counts` string, nullable: Step numbers to keep, as singletons and/or ranges (e.g. '0-2,5,8-10')
- `cycle_counts` string, nullable: Comma-separated list of cycle counts to filter (e.g., '1,2,3')
- `x_min` number, nullable: Minimum x-axis value to filter
- `x_max` number, nullable: Maximum x-axis value to filter
- `x_column` string, nullable: Column name for x-axis filtering (e.g., 'Time [s]' or 'Capacity throughput [A.h]')
- `include_steps` boolean: Include steps in response.
- `include_time_series` boolean: Include time_series in response.

## Response `200`

Successful Response

- CellMeasurementDetail: Response model for the /detail endpoint for a single measurement.
  - `is_failed` boolean: Whether it was reported as failed.
  - `failure_reason` string, nullable: Why it failed.
  - `failed_at` string, date-time, nullable: When it was reported.
  - `failed_by` string, nullable: User who reported it.
  - `name` string, required
  - `protocol` object, nullable: Protocol information. Typical keys: 'name' (str), 'ambient_temperature_degc' (float), 'definition' (dict | str — a UCP protocol definition or another protocol format).
  - `start_time` string, date-time, nullable: ISO 8601 datetime with timezone (UTC preferred) marking when the test started.
  - `end_time` string, date-time, nullable: ISO 8601 datetime with timezone (UTC preferred) marking when the test finished. Leave null while the test is still running; set it once the measurement is complete. A null end_time means the cell is still considered 'on test' in the Lab view.
  - `estimated_end_time` string, date-time, nullable: ISO 8601 datetime with timezone (UTC preferred) forecasting when a still-running test will finish. Distinct from end_time (the actual finish): this is an estimate. Null when no estimate has been computed yet.
  - `estimated_end_time_note` string, nullable: Free-text explanation of how estimated_end_time was derived.
  - `estimated_end_time_calculated_at` string, date-time, nullable: ISO 8601 datetime with timezone marking when estimated_end_time was last computed.
  - `test_setup` object, nullable: Physical test setup. Typical keys: 'cycler' (model), 'operator', 'lab', 'channel_number'. Readers also record what the cycler header carries, drawn from one shared vocabulary so the shape does not vary by cycler: 'test_name', 'cell_label' (the cycler's own label for the cell, which need not match the cell instance), 'instrument', 'cycler_serial_number', 'software_version', 'temperature_setpoint_degc', 'notes', 'end_time', plus export provenance -- 'export_date', 'source_file_path', 'barcode_comment', and 'source_file_id' (an id in the cycler's own id space, not a cross-system identifier). Which of these a file can fill depends on its format; keys the header does not carry are omitted rather than set empty.
  - `notes` string, nullable: Free-text notes about the cell measurement
  - `measurement_type` 'time_series' | 'file' | 'properties': Shape of the data stored in a cell measurement. - ``time_series`` — cycling / diagnostic data uploaded as columnar time series (and optional step summaries). Default for new measurements. - ``file`` — an opaque file upload (raw cycler export, image, other binary). Metadata about the file is captured in ``file_metadata``; the file content lives in object storage. - ``properties`` — a flat key/value set of measured properties (thickness, mass, DCIR, initial capacity, …) with no time-series data. Numeric values use the Quantity format.
  - `properties` object, nullable: Flat key/value measurements, populated only when measurement_type is 'properties'. Numeric values use the Quantity format. Example: {'thickness': {'value': 0.52, 'unit': 'mm'}, 'DCIR': {'value': 12, 'unit': 'mohm'}}.
  - `file_metadata` object, nullable: Metadata about uploaded files (MIME types, dimensions, etc.)
  - `channel_id` string, nullable: Optional ID of the channel this measurement ran on.
  - `protocol_id` string, nullable: Optional ID of the experiment template (protocol) this measurement was run against.
  - `program_id` string, nullable: Optional catalog program for this measurement (copied from a linked planned measurement when present).
  - `tags` string[]: Free-form labels for organising and filtering measurements, e.g. ['baseline', 'batch-7']. Whitespace is trimmed, duplicates are dropped case-insensitively, and a tag already used in the project keeps its existing spelling. At most 50 tags of up to 50 characters.
  - `id` string, required
  - `cell_instance_id` string, required
  - `organization_id` string, required: Organization this measurement belongs to.
  - `project_id` string, required: Project this measurement belongs to
  - `created_by` string, nullable: User ID of the user who created this measurement
  - `created_by_email` string, nullable: Email of the user who created this measurement
  - `processing_status` 'pending' | 'running' | 'ready' | 'failed' | 'awaiting_extend' | 'extending': Lifecycle of a measurement's step processing, shared with extend. - ``pending`` — confirm-upload task enqueued. - ``running`` — worker parsing the upload or calculating steps. - ``ready`` — terminal success; default for ``file``/``properties``. - ``failed`` — permanent; see ``processing_error``. - ``awaiting_extend`` — claim held, signed URL out, no task queued. - ``extending`` — delta staged, stitch queued or running. Only ``ready`` may start an extend, so it cannot overlap step processing (both write ``steps.parquet``). A failed extend returns to ``ready``.
  - `processing_error` string, nullable: Reason processing failed, when processing_status is 'failed'. Also carries why an extend did not apply, in which case the status is back to 'ready' and this is advisory only.
  - `source_etag` string, nullable
  - `row_count` integer, nullable
  - `time_series_bytes` integer, nullable
  - `recorded_duration_s` number, nullable
  - `accepts_raw_updates` boolean
  - `estimated_end_time_status` 'estimating' | 'ready' | 'failed': Lifecycle of a duration estimate computed by a background simulation. Used by both estimates: a planned test's total duration (``planned_measurements.estimated_duration_*``) and a running test's remaining duration (``cell_measurements.estimated_end_time_*``). One enum because the lifecycle is identical -- only what is being estimated differs. ``estimating`` while the job is in flight, ``ready`` once a value came from it, ``failed`` with the reason in the accompanying note. ``None`` means no estimate was ever requested.
  - `estimated_end_time_job_id` string, nullable
  - `created_at` string, date-time, required
  - `updated_at` string, date-time, required
  - `extend_claim_id` string, nullable: Opaque token identifying the in-flight extend that holds this measurement, and the staging prefix its delta is uploaded to. Non-null exactly while processing_status is 'awaiting_extend' or 'extending'.
  - `extend_in_progress_at` string, date-time, nullable: Deprecated and always null. Use processing_status.
  - `extend_claimed_at` string, date-time, nullable: When the in-flight extend claim was taken. Written only by the claim itself, so an unrelated update to the measurement does not age it. Null when no extend holds the measurement.
  - `steps` object, nullable
  - `time_series` object, nullable
  - `cycles` object, nullable
  - `specification` CellSpecification, required: Model representing a cell specification as returned by the API.
    - `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.
  - `instance` CellInstance, required: Model representing a cell instance as returned by the API.
    - `is_failed` boolean: Whether it was reported as failed.
    - `failure_reason` string, nullable: Why it failed.
    - `failed_at` string, date-time, nullable: When it was reported.
    - `failed_by` string, nullable: User who reported it.
    - `name` string, required: Name of the cell instance (serial number)
    - `batch_id` string, uuid, nullable: Manufacturing lot (cell batch) this cell came from. Must be a batch of the same cell specification.
    - `date_manufactured` string, date, nullable: Date of manufacture
    - `measured_properties` object, nullable: Measured (not designed) properties of this specific cell, grouped by component. Numeric values use the Quantity format. Example: {'cathode': {'loading': {'value': 7.06, 'unit': 'mg.cm-2'}}, 'cell': {'initial_capacity': {'value': 1.08, 'unit': 'A.h'}}}. Designed properties (target loading, rated capacity) belong on the cell specification.
    - `notes` string, nullable: Free-text notes about the cell instance
    - `id` string, required: Unique identifier for the cell instance
    - `cell_specification_id` string, required: Foreign key to the cell specification
    - `organization_id` string, required: Organization this cell instance belongs to.
    - `project_id` string, required: Project this cell instance belongs to
    - `created_by` string, nullable: User ID of the user who created this instance
    - `created_by_email` string, nullable: Email of the user who created this instance
    - `created_at` string, date-time, required: Timestamp when the instance was created
    - `updated_at` string, date-time, required: Timestamp when the instance was last updated
    - `batch_name` string, nullable: Name of the batch ``batch_id`` points at. Read-only.
    - `measurement_ids` object[], nullable: List of measurement IDs associated with the cell instance

## Other responses

- `422`: Validation Error

## Changes

- **2026-10-24** `f4c74e855466`: 8 info
  - added the optional property `failed_at` to the response with the `200` status
  - added the optional property `failed_by` to the response with the `200` status
  - added the optional property `failure_reason` to the response with the `200` status
  - added the optional property `instance/failed_at` to the response with the `200` status
  - …4 more
- **2026-10-09** `d01ecf131915`: 1 info
  - added the optional property `accepts_raw_updates` to the response with the `200` status
- **2026-10-06** `6fbec094b30e`: 14 info
  - added the optional property `specification/ratings/acir_1khz` to the response with the `200` status
  - added the optional property `specification/ratings/charge_cutoff_current` to the response with the `200` status
  - added the optional property `specification/ratings/charge_temperature_max` to the response with the `200` status
  - added the optional property `specification/ratings/charge_temperature_min` to the response with the `200` status
  - …10 more
- **2026-10-04** `1f50d4b61910`: 1 warning, 7 info
  - removed the optional property `instance/batch` from the response with the `200` status
  - added the optional property `instance/batch_id` to the response with the `200` status
  - added the optional property `instance/batch_name` to the response with the `200` status
  - added the optional property `specification/cad_file_name` to the response with the `200` status
  - …4 more
- …earlier changes not shown

[Operation history](https://skmtc.dev/ionworks/apis/ionworks-api/changes/cell_measurements/:measurement_id/detail/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)