# Operation types

An **operation type** is the definition of an action: its name, its title and description, the entity
types it applies to, its parameter schema and its steps. Nothing can be executed until an operation
type for it exists in your organization.

There are two ways to get one:

- **Clone it from the platform catalog**, for the operations OpenGate already implements. See the
  [default operations catalog](../default_catalog/).
- **Create it from scratch**, for actions specific to your devices.

{{% notice style="primary" title="Only your organization's types are executable" icon="triangle-exclamation" %}}
Operation types from the platform catalog that have **not** been cloned into your organization cannot be
executed. The catalog is a source to inherit from, not a set of ready-to-run operations.
{{% /notice %}}

| Resource | Contains |
|---|---|
| `/v80/operationTypes/catalog` | The platform catalog, available to be cloned |
| `/v80/operationTypes/provision/organizations/{organization}` | Your organization's own operation types |

## What the API does

- Retrieve the list of operations available to be cloned.
- Create operations for an organization, either by cloning from the catalog or from scratch.
- Retrieve a single operation from the catalog by name.
- Update an operation previously created.
- Delete an operation previously created.
- Search the operations of an organization using the platform's filters.

{{% notice style="info" title="Viewer profile" icon="lightbulb" %}}
GET and SEARCH are the only actions available to the `viewer` profile.
{{% /notice %}}

## Creating an operation type

The response returns a `location` header with the URL of the new resource.

When the operation is **cloned from the catalog**, only `name`, `description` and `title` can be
modified — the parameter schema, the steps and the applicability of a catalog operation are fixed. When
created from scratch, you define all of it, including the
[parameter schema](../parameters/).

### Restricting execution by profile

The optional `profiles` list names the user profiles authorized to execute the operation. By default,
every profile except `viewer` can execute custom operations.

Available profile names:

- `advanced`
- `admin_domain`
- `super_admin_domain`
- `admin`
- `root`

The list can be set at creation time or updated later. If omitted, the default access rules apply.
Invalid profiles return `400 Bad Request` with error detail; `viewer` is never permitted and also
returns `400` if included.

## Updating an operation type

For operations derived from the catalog, only `name`, `description` and `title` can be modified.

## Searching operation types

Five filter fields are available, all optional:

| Filter | Selects by |
|---|---|
| `name` | Operation name |
| `applicableTo` | Entity type the operation applies to |
| `models` | Device models the operation supports |
| `fromCatalog` | Whether the operation was cloned from the platform catalog |
| `profile` | Profiles authorized to execute it |

{{% notice style="info" title="Extended operation fields" icon="lightbulb" %}}
Any parameter of the `ExtendedOperation` object can also be used as a filter field in `operationTypes`
searches.
{{% /notice %}}

## Usage examples

Read the operation types catalog:

```bash
curl --request GET \
     --header "X-ApiKey: <your-api-key>" \
     https://www.amplia-iiot.com/v80/operationTypes/catalog
```

Read a single operation type of your organization by its name:

```bash
curl --request GET \
     --header "X-ApiKey: <your-api-key>" \
     https://www.amplia-iiot.com/v80/operationTypes/provision/organizations/{organizationName}/REBOOT_EQUIPMENT
```

## API specification

{{< openapi src="operations_api.yaml" >}}