Site operations

CREATE_SITES

Used to add new sites to the platform in bulk.

Operation structure:

{
    "operation": "CREATE_SITES",
    "params": {
        "cross_operator_match_distance_m": 100
    },
    "data": [
	      ...
    ]
}

Parameters:

• cross_operator_match_distance_m: cross operator matching distance (see Matching)
• enable_cross_operator_matcher: whether to run the cross operator matcher (optional, defaults to true)
  • Set to false on large imports — the matcher loads all infrastructure into memory.
• run_matchers_post_import: whether to run emission matching after the import (optional, defaults to true)
  • Set to false to skip the RunMatchers and ProcessNonDetects steps. Site preset and timezone updates still run.

Data fields (all fields are required, even if empty!):

Parameter	Type	Example
owner	Operator name (as stored in platform)	N100
site_name	string	Bakerfield S-12
date_of_installation	date	2022-10-12
operator_status	string	ACTIVE
subpart_w_segment	string	OOOOb
operator_unique_id	string	DPST-12345
other_operator_ids	string	ALS-123,TGBD-1234
geometry	String representation of GeoJSON or WKT. Accepts only Polygon and Point geometries!	{\\"type\\": \\"Point\\",\\"coordinates\\": [-106.84455467396093, 34.78297044770471]} POINT (-106.84455467396093 34.78297044770471
geometry_source	One of UNKNOWN, BRIDGER, OPERATOR_PROVIDED, DRAWN_BY_AERSCAPE, SCRAPED_FROM_PUBLIC_DATA, GROUND_SURVEY	GROUND_SURVEY
start_date	date	2022-10-12
end_date	date	2022-10-12
change_transactions	List of objects (any valid JSON object is accepted)	[{}, {}] [{"date": "2020-10-12", "operation": "import from operator DB"}]
site_data_source	string	"operator GIS database" "bridger import"
site_type_from_imagery	string	"well_site" "processing_facility"
equipment	A list of equipment, containing ALL parameters from the CREATE_EQUIPMENT operation, with the exception of owner and site since these will be taken from the parent site.	See Data fields (all fields are required, even if empty!)
sensor_config	JSON object with sensor integration config (optional) — see Sensor Data	{"sensors": [{"id": "device-1", "provider": "sensirion"}], "sensirion_site_id": "SITE-001", "longpath_site_id": "LP-001"}
responsible_person	Email address of a platform user who is a member of the site's owner company (optional). Sets the site's real Responsible Person relation — not extra_data. See Responsible person. Legacy alias: responsible_person_id.	jane.doe@operator.com
Any other fields	string (will be stored inside extra_data). A column matching one of the documented fields above is never also copied into extra_data.	{}

UPDATES_SITES

Similar to the previous operation, but with the goal updating data for already existing sites.

Operation structure:

{
    "operation": "UPDATE_SITES",
    "params": {
        "cross_operator_match_distance_m": 100
    },
    "data": [
        ...
    ],
}

Parameters:

• cross_operator_match_distance_m: cross operator matching distance
  • The cross-operator matcher will run only if the geometry column is provided.
• enable_cross_operator_matcher: whether to run the cross operator matcher (optional, defaults to true)
  • Set to false on large imports — the matcher loads all infrastructure into memory.
• run_matchers_post_import: whether to run emission matching after the import (optional, defaults to true)
  • Set to false to skip the RunMatchers and ProcessNonDetects steps. Site preset and timezone updates still run.

Data fields:

Parameter	Type	Example
id	string - ID of site already in the database	12345678-1234-5678-1234-567812345678
owner	non-editable (don't send or send blank)
All other properties	Same as the the CREATE_SITES operation	See previous operation table.

Only send the fields you want to modify (empty fields will be changed to empty values if provided!).

Responsible person

The responsible person is a real relation on the site, not an extra_data entry. It is what the assign_responsible workflow action uses to pick an assignee for emission events, and it is shown as the Responsible row on the site details panel.

Set it by passing the user's email address in the responsible_person column of CREATE_SITES or UPDATE_SITES:

{
    "operation": "UPDATE_SITES",
    "data": [
        {
            "id": "12345678-1234-5678-1234-567812345678",
            "responsible_person": "jane.doe@operator.com"
        }
    ]
}

Rules:

• The user must already exist on the platform. An unknown address fails the row with Object with email=<value> does not exist. — the import never creates users.
• The user must be a member of the site's owner company, otherwise the row fails with User '<email>' is not a member of the site's company. A user belongs to exactly one company.
• Infrastructure imports are all-or-nothing (a single transaction — see Infrastructure import), so either failure rolls back the entire import, not just the offending row.
• Emails are matched exactly and platform emails are always stored lowercase, so send the address in lowercase. Jane@Operator.com will not resolve.
• Send null or an empty string to clear the responsible person. Only omitting the column from an UPDATE_SITES row preserves the current value.

An empty column unassigns the site

The convention elsewhere on this page is to send every column even when empty. That does not work here: a row containing "responsible_person": "" clears the relation. If you generate update rows from an export that always emits every column, leave responsible_person out entirely unless you intend to change it — otherwise you will unassign every site in the file.

• responsible_person_id is a legacy alias for the same field and still works. Prefer responsible_person, which matches the name used by the site API. Sending both columns with different values fails the row.

Do not use a custom column

Do not add a column such as Site Responsible or responsible. Any column that is not a documented field is stored in extra_data, where nothing on the platform reads it — it only shows up as a duplicate row on the site details panel, and it will not assign the responsible person.

Legacy extra_data entries

Imports run before this behaviour was corrected also copied the responsible_person_id column into extra_data, so some sites still carry a stale responsible_person_id entry there and show it as a duplicate row. The relation itself was always set correctly; the extra_data copy is unread and is never refreshed when the responsible person changes. Those leftover entries are being removed separately — do not rely on them, and do not reference them from workflow conditions or linking rules.

TRANSFER_SITES

Transfers sites to a new owner by creating copies with the new ownership while deactivating the original sites.

This operation will:

1. Validate all site IDs exist in the system before proceeding.
2. Create new site records under the new owner, with a start date of either today or the specified move_date.
3. Transfer all equipment from original sites to the new sites, updating ownership information.
4. Deactivate original sites by setting their end_date to the transfer date.
5. Record transfer history in the change_transactions field of new sites.
6. Copy emission records and marks them as completed, without bringing any inputs from the previous operator.

Operation structure:

{
    "operation": "TRANSFER_SITES",
    "params": {
        "new_owner": "N345",
        "move_date": "2020-01-01"
    },
    "data": [
        "aerscape-id-1",
        "aerscape-id-2",
        ...
    ]
}

Parameters:

• new_owner: (Required) Company code/name of the new owner. Must exist in the system.
• move_date: (Optional) Date when the transfer should be recorded, in YYYY-MM-DD format. Defaults to current date if not provided.

Data: An array of site IDs to transfer to the new owner. All IDs must be valid site primary keys in the database.

Error Conditions:

• Fails if the specified company (new_owner) doesn't exist.
• Fails if any site ID in the data array is invalid.
• Fails if the provided move_date is not in a valid ISO format.

MERGE_SITES

Merges multiple sites from the same owner into a single new site.

This operation will:

1. Create a new site with the provided properties
2. Reassign all equipment from the original sites to the new site
3. Move all aerial images from the original sites to the new site
4. Update all emission records to reference the new site
5. Update all site matches in emission records
6. Delete the original sites

Operation structure:

{
    "operation": "MERGE_SITES",
    "params": {
        "site_data": {
            "owner": "CompanyName",
            "site_name": "Merged Site",
            "date_of_installation": "2025-01-01",
            "operator_status": "Active",
            "subpart_w_segment": "OOOOb",
            "start_date": null,
            "end_date": null,
            "operator_unique_id": "TS1",
            "other_operator_ids": "TS1-ALT,TESTCO-TS1",
            "geometry": {"type": "Point", "coordinates": [-103.475, 31.765]},
            "geometry_source": "OPERATOR_PROVIDED",
            "change_transactions": [{"type": "create", "date": "2025-01-01"}],
            "site_data_source": "Import Source",
            "extra_field": "Extra Value"
        }
    },
    "data": [
        "site-id-1",
        "site-id-2",
        "site-id-3"
    ]
}

Parameters:

• site_data: (Required) A complete specification for the new site that will be created to replace the merged sites. This should contain all the same fields as would be used when creating a new site.

Data: An array of site IDs to merge. All sites must:

• Be valid site IDs in the database
• Belong to the same owner
• The owner must match the owner specified in the site_data

Error Conditions:

• Fails if any site ID in the data array is invalid
• Fails if the sites to be merged have different owners
• Fails if the new site owner doesn't match the owner of the sites to be merged
• Fails if the site_data is invalid or missing required fields

Effects:

When this operation runs successfully:

1. A new site is created with the properties from site_data
2. All equipment from the original sites is moved to the new site
3. All aerial images from the original sites are moved to the new site
4. All emission records that referenced the original sites are updated to reference the new site
5. All site matches in emission records are updated, removing references to the original sites and adding a reference to the new site
6. The original sites are permanently deleted

SPLIT_SITES

Splits a single site into multiple new sites, redistributing equipment, aerial images, and emission records.

This operation will:

1. Create multiple new sites based on the provided specifications
2. Redistribute equipment to specified new sites or to the nearest new site based on spatial proximity
3. Reassign aerial images to the nearest new site based on spatial proximity
4. Update emission records to reference the closest new site based on the emission location
5. Update site matches in emission records to include all new sites
6. Delete the original site

Operation structure:

{
    "operation": "SPLIT_SITES",
    "params": {
        "site_to_split": "site-id-to-split"
    },
    "data": [
        {
            "owner": "CompanyName",
            "site_name": "Split Site 1",
            "date_of_installation": "2025-01-01",
            "operator_status": "Active",
            "subpart_w_segment": "OOOOb",
            "start_date": null,
            "end_date": null,
            "operator_unique_id": "SS1",
            "other_operator_ids": "SS1-ALT,TESTCO-SS1",
            "geometry": {"type": "Polygon", "coordinates": [[[-103.475, 31.765], [-103.465, 31.765], [-103.465, 31.775], [-103.475, 31.775], [-103.475, 31.765]]]},
            "geometry_source": "OPERATOR_PROVIDED",
            "change_transactions": [{"type": "split", "date": "2025-01-01"}],
            "site_data_source": "Site Split Operation",
            "equipment": ["equipment-id-1", "equipment-id-2"]
        },
        {
            "owner": "CompanyName",
            "site_name": "Split Site 2",
            "date_of_installation": "2025-01-01",
            "operator_status": "Active",
            "subpart_w_segment": "OOOOb",
            "start_date": null,
            "end_date": null,
            "operator_unique_id": "SS2",
            "other_operator_ids": "SS2-ALT,TESTCO-SS2",
            "geometry": {"type": "Polygon", "coordinates": [[[-103.495, 31.785], [-103.485, 31.785], [-103.485, 31.795], [-103.495, 31.795], [-103.495, 31.785]]]},
            "geometry_source": "OPERATOR_PROVIDED",
            "change_transactions": [{"type": "split", "date": "2025-01-01"}],
            "site_data_source": "Site Split Operation",
            "equipment": ["equipment-id-3", "equipment-id-4"]
        }
    ]
}

Parameters:

• site_to_split: (Required) The ID of the site that should be split into multiple sites.

Data: An array of site specifications for the new sites that will be created from the split. Each site specification should contain all the same fields as would be used when creating a new site, plus:

• equipment: (Optional) An array of equipment IDs from the original site that should be explicitly assigned to this new site.

Requirements:

• All new sites must have the same owner as the site being split
• All new sites must have a valid shape (geometry)
• The site to split must exist in the database
• All equipment without location must be explicitly assigned to new sites
• All equipment IDs must belong to the original site

Error Conditions:

• Fails if the site_to_split ID is invalid
• Fails if any new site has a different owner than the site being split
• Fails if any new site specification is missing a shape
• Fails if the site specifications are invalid or missing required fields
• Fails if any equipment ID in the equipment lists doesn't exist or doesn't belong to the original site
• Fails if any equipment without location is not explicitly assigned to a new site

Effects:

When this operation runs successfully:

1. New sites are created according to the provided specifications
2. Equipment from the original site is reassigned to new sites:
   • Equipment explicitly listed in a site's equipment array is assigned to that site
   • Equipment not explicitly assigned is assigned to the closest new site based on spatial proximity
3. Aerial images from the original site are reassigned to the closest new site based on spatial proximity
4. Emission records that referenced the original site are updated to reference the closest new site based on the emission location
5. Site matches in emission records are updated to include all the new sites
6. The original site is permanently deleted