opentrons-integration skill

Opentrons Integration

Overview

Create production-minded Python Protocol API v2 protocols for Opentrons Flex and OT-2. This skill covers protocol structure, hardware and deck configuration, liquid handling, runtime customization, module control, simulation, and safe deployment.

The verified baseline as of 2026-07-23 is:

• opentrons==9.1.1 for reproducible Flex simulation.
• opentrons==9.0.0 for local OT-2 API 2.28 compatibility simulation.
• Flex supports API levels 2.15 through 2.29 on current software.
• OT-2 supports API levels 2.0 through 2.28 on current software.
• API 2.29 is Flex-only at this baseline. Do not put 2.29 in an OT-2 protocol.

Read references/sources.md for the upstream documentation used for this snapshot. Recheck the official versioning page before targeting newer robot software.

Safety Boundary

Opentrons protocols control physical equipment. Never treat successful Python syntax or local simulation as permission to run on a robot.

Before live execution:

analysis.

1. Simulate locally with the same pinned opentrons version used for authoring.
2. Import the protocol into the correct Opentrons App and require successful

definitions, deck fixtures, tip count, source volumes, dead volumes, and destination capacity.

1. Verify robot model, software, pipettes, mounts, modules, adapters, labware

labware, partial tip pickup, or gripper moves are new.

1. Review the run preview and deck map with the operator.
2. Perform a slow dry run with nonhazardous liquid when geometry, custom

chemical-safety, and contamination-control procedures.

1. Keep the emergency stop accessible and follow site-specific biosafety,

Simulation cannot verify physical calibration, liquid properties, meniscus behavior, labware manufacturing tolerances, cap or seal removal, tubing, or all possible collisions.

Choose the Right Interface

Use this skill for Python files imported into the Opentrons App and run through the Protocol API.

control is explicitly required, use the OpenAPI document served by the target robot and do not infer endpoints from Protocol API methods.

• Use Protocol Designer for supported no-code workflows.
• Use PyLabRobot for a hardware-agnostic workflow spanning vendors.
• Treat the robot's HTTP API as a separate integration surface. If direct HTTP

Required Intake

Do not write final protocol code until these facts are known:

characteristics.

• Robot: Flex or OT-2, plus installed robot software.
• Pipette model, volume range, channel count, and mount.
• Modules and generations; Flex Gripper or Stacker availability.
• Exact labware API load names and custom definition files, if any.
• Deck fixtures: Flex trash bin, waste chute, staging slots, or Stackers.
• Source volumes, destination volumes, dead volume, mixing needs, and liquid

and total tips.

• Tip policy: contamination boundaries, reuse policy, filters, partial pickup,

files.

• Operator interventions, incubation timing, runtime parameters, and output

plan.

• Acceptance criteria: tolerated volume error, required controls, and dry-run

If any physical configuration is uncertain, produce a parameterized draft and an explicit assumptions list rather than guessing.

Install and Simulate

Flex:

uv run --with "opentrons==9.1.1" opentrons_simulate protocol.py

OT-2 API 2.28:

uv run --with "opentrons==9.0.0" opentrons_simulate protocol.py

The 9.1.1 package intentionally rejects OT-2 protocols after the Flex/OT-2 release-line split. Always complete OT-2 analysis in the current OT-2 App.

For a dedicated Flex environment:

uv venv --python 3.10
uv pip install --python .venv/bin/python -r skills/opentrons-integration/requirements-flex.txt
.venv/bin/opentrons_simulate protocol.py

Use requirements-ot2.txt instead for an OT-2 compatibility environment. On Windows, invoke the executable from .venv\Scripts\opentrons_simulate.exe. Local simulation is for Python protocols; import Protocol Designer JSON files into the appropriate Opentrons App instead.

Protocol Skeletons

Flex, API 2.29

For Flex, requirements is mandatory. Put apiLevel only in requirements, not in both metadata and requirements.

from opentrons import protocol_api

metadata = {
    "protocolName": "Flex transfer",
    "author": "Your Name",
    "description": "Transfer buffer into a plate.",
}
requirements = {"robotType": "Flex", "apiLevel": "2.29"}


def run(protocol: protocol_api.ProtocolContext) -> None:
    tips = protocol.load_labware(
        "opentrons_flex_96_tiprack_200ul", "D1"
    )
    reservoir = protocol.load_labware("nest_12_reservoir_15ml", "D2")
    plate = protocol.load_labware("nest_96_wellplate_200ul_flat", "C2")
    protocol.load_trash_bin("A3")
    pipette = protocol.load_instrument(
        "flex_1channel_1000", "left", tip_racks=[tips]
    )

    pipette.transfer(
        100,
        reservoir["A1"],
        plate["A1"],
        new_tip="always",
    )

OT-2, API 2.28

For OT-2 API 2.15 and later, a requirements block is recommended. OT-2 has a fixed trash in slot 12; do not call loadtrashbin().

from opentrons import protocol_api

metadata = {
    "protocolName": "OT-2 transfer",
    "author": "Your Name",
}
requirements = {"robotType": "OT-2", "apiLevel": "2.28"}


def run(protocol: protocol_api.ProtocolContext) -> None:
    tips = protocol.load_labware("opentrons_96_tiprack_300ul", "1")
    reservoir = protocol.load_labware("nest_12_reservoir_15ml", "2")
    plate = protocol.load_labware("nest_96_wellplate_200ul_flat", "3")
    pipette = protocol.load_instrument(
        "p300_single_gen2", "left", tip_racks=[tips]
    )
    pipette.transfer(100, reservoir["A1"], plate["A1"])

Use the lowest API level that provides every required feature when a protocol must run across a mixed software fleet. Use the current maximum only when the workflow needs its behavior or capabilities.

Authoring Workflow

1. Select robot and API level

Check the maximum supported API in the App under the robot's advanced settings. Map every requested feature to its minimum API level using references/api_reference.md.

Important gates:

nozzle layouts.

• 2.20: CSV runtime parameters, liquid presence detection, expanded partial

• 2.21: Absorbance Plate Reader.
• 2.22: current labware-level liquid loading methods.
• 2.23: meniscus locations and labware lids.
• 2.24: liquid classes and liquid-class complex commands.
• 2.25: Flex Stacker and Flex 96-Channel 200 µL pipette.
• 2.27: dynamic pipetting and concurrent module actions.
• 2.28: 20 µL Flex tips, improved partial-tip return, and thermocycler ramp rate.
• 2.29: step grouping; Flex only at the verified baseline.

2. Build the deck explicitly

and tall-labware adjacency.

• Use exact load names from the official Labware Library.
• Load Flex trash bins or the waste chute explicitly.
• Account for module footprints, staging slots, Stacker shuttles, gripper paths,