Developer Programme

2025 Q2 Updates

1. Inspection Ops Service has been bumped to version 2.x. 1.x will cease to be supported. Highlight of non-backwards compatible changes:
   1. Multiple non-essential fields removed from facilities and inspection
   2. Deprecating facility affiliated_companies, inspection personnel and all cross company access. All data now 100% private to company
   3. Facility elevation (previously an internal construct) now exposed via API as well.
2. Still in alpha, available only to select customers: Machine Learning endpoints launched to support custom ML services.

Inspection Ops Service Migration Guide

If you have Building Facade Inspection API category enabled and use Inspection Ops Service, please see the full migration guide from 1.x.x to 2.x.x below:

Schema changes

Generally, all _id has been deprecated. Please switch to using the entity specific id, e.g. inspection_id

1. Facility:
   • Removed affiliated_companies, notes, properties, elevations (replaced by Facility Elevations), inspections (from version 0.x)
   • Removed _id, please use facility_id
   • Concept change: Previously, Facility is owned by the Building Owner. That will no longer be the case as we gear the app towards a singular customer profile: the Inspection Body, defined by ISO/IEC 17020 (see Technical Note FI 01 for full description).
2. Facility Elevation:
   • New schema for Facility Elevation now available
   • No _id, please use elevation_id
3. Inspection:
   • Replaced personnel to pilots and inspectors. There is no more inspection specific role (ie. only the general app role applies)
   • Removed _id, please use inspection_id

Endpoint Changes

No major endpoint changes, mostly bug squahsed, the most significant one is that the system used to take arbitrary fields not specified in the API. We have ended this practise from v2.0 onwards.

2025 Q1 Updates

1. Aircraft Service has been bumped to version 2.x. 1.x will cease to be supported. Highlight of non-backwards compatible changes:
   1. drone_providers is now just providers in all schemas
   2. removed denormalised query for providers (removed provider query parameter)
   3. added / aligned other query parameters with other aircraft equipment.
2. Drone Simulators will now automatically stop after 24 hours of use. We recommend you stop the simulator once you are done.

Airspace Service Migration Guide

If you have UAS Fleet Management API category enabled and use Aircraft Service, please see the full migration guide from 1.x.x to 2.x.x below:

Schema changes

1. Drone Model and Dock Model:
   • Replace all existing drone_provider_ids and dock_provider_ids with provider_ids.
2. Drone and Dock
   • Replace all existing drone_provider_id and dock_provider_id with provider_id.
3. Payload Model:
   • weight: string → number (align with other equipment weights)
   • dimension.*: string → number (align with other equipment dimension), and dimension no s.
4. Dock Model and Payload Model:
   • Added standardized fields: control_interface, control_metadata, compatible_drone_models for integration needs. Can be ignored for the most part of the integration happens at the Drone level, useful when the payload and the drone speak in a different protocol.

Endpoint Changes (General)

1. Replace all calls to /drone-providers and /dock-providers with /providers
2. Replace all existing query parameters with drone_provider_id with provider_id
3. Remove the existing provider or providers query parameter. A separate query to /providers will be necessary to get provider information if needed.
4. (optional) Add limit query parameter to any end point to limit the number of results.
5. (super admin only) Add company_ids query parameter to enlarge the search for Equipments or Flights to cover the specified companies.
6. (super admin only) Add all_companies query parameter to query against all companies in the given server instance to search for Equipments and Flights.

Reminder: what used to be a separate table between cameras and payloads has been combined as just payloads with the additional properties in cameras captured under camera_properties in payloads. You will find all previous cameras migrated soon.

Endpoint changes to /drone-models

Deleting a drone model used to be a soft delete. This has been changed to a hard delete to align with all other equipment model’s behaviour. If you need to retain the soft delete, use PATCH endpoint with status: 'deleted' instead. This also implies deletion of a drone model is not allowed unless there are no drones pointing at it (including soft deleted ones)

Endpoint changes to /dock-models

Deleting a dock model used to be a soft delete. This has been changed to a hard delete to align with all other equipment model’s behaviour. If you need to retain the soft delete, use PATCH endpoint with status: 'deleted' instead. This also implies deletion of a dock model is not allowed unless there are no docks pointing at it (including soft deleted ones)

Endpoint changes to /flights

1. All insurance policies related data has been deleted from the system as it’s been 4 years since the shut down of CoverFlight. The field policies no longer exist.
2. Previously, due to a higher audit requirement that was only applicable to the Flights table, the name of Batteries, Cameras, and Payloads were copied to Flight table’s batteries, cameras, and payloads field respectively. This results in an incomplete record.
   1. Moving forward, these 3 fields will be retired, and their ids retained in the Flight table’s drone.battery_ids and drone.payload_ids respectively.
   2. A separate query to either of this table gives not just the name but the full record of the equipment.
   3. Care should be taken to avoid changing the equipment’s attributes / reusing equipment IDs.
   4. Equipment attached to the drone will be found in the drone nested object, such as drone.tracker_ids. Equipment used that are part of the flight but not mounted on the drone will have its own entries e.g. dock or controller.
   5. Replace query parameters trackers, batteries, cameras, and payloads with tracker_id, battery_id, and payload_id. They are now for exact matches only.
3. Remove query parameter deployment_id as it no longer works (a subsequent deprecation will occur where deployments will be migrated to security incidents.