Migrating from Tasks to Actions

The Tasks and Registry actions endpoints are deprecated. They are replaced by two resources that separate what you can trigger from what you have triggered.

Nothing breaks today. The deprecated endpoints keep working and keep returning the same responses. Migrate when it suits you.

What replaces what

Deprecated	Replacement
`GET /registry-actions`	`GET /actions`
`POST /tasks`	`POST /action-runs`
`GET /tasks/{taskId}`	`GET /action-runs/{actionRunId}`

The two resources

/actions is the catalogue. It lists the actions your workspace can trigger, and the payloadSchema each one accepts.

/action-runs is the log. Each run records one invocation: its status, its error if it failed, and who triggered it.

How to migrate

Trigger an action

The request body does not change.

curl -X POST https://api.corma.io/v1/action-runs \
  -H "x-corma-api-key: $CORMA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "actionIdentifier": "corma.create_provisioning_ticket", "payload": { "ID": 42 } }'

The response is the same shape as before, and the status code is still 202.

Read a run

Replace the path. The taskId you already hold is the same value as actionRunId — the resource was renamed, not re-keyed.

curl https://api.corma.io/v1/action-runs/1041 \
  -H "x-corma-api-key: $CORMA_API_KEY"

What is new

Two reads that had no equivalent before.

List the runs in your workspace. Previously a run could only be read by an id you kept from the trigger response. If you lost that id, the run was unreachable.

curl "https://api.corma.io/v1/action-runs?filters[status][in]=errored" \
  -H "x-corma-api-key: $CORMA_API_KEY"

Runs are returned most recent first, and can be filtered by status, source, actionIdentifier and triggeredById.

The log covers every action run in the workspace, not only the ones you triggered through this API. A run started by an administrator in the Corma web app appears here too. Each run carries a source saying which it was, so filter on it for the narrower view:

curl "https://api.corma.io/v1/action-runs?filters[source][in]=public_api" \
  -H "x-corma-api-key: $CORMA_API_KEY"

Read one action definition. Previously you had to list the whole catalogue and filter client-side.

curl https://api.corma.io/v1/actions/corma.create_provisioning_ticket \
  -H "x-corma-api-key: $CORMA_API_KEY"

Response changes

status now documents three values instead of six: ongoing, completed and errored. The three no longer listed — draft, todo and declined — belonged to an internal concept that no longer exists, and are not returned by this API. If your integration branches on them, those branches were already unreachable and can be removed.

Runs carry a new source field, described above.

If you generate a client from our OpenAPI document, some type names change. The wire format is identical and no field is removed, but the schema components were renamed to match the new resources:

Was	Is now
`Task`	`ActionRun`
`CreateTaskBody`	`CreateActionRunBody`
`TaskStatus`	`ActionRunStatus`
`RegistryAction`	`Action`
`RegistryActionFilter`	`ActionFilter`
`RegistryActionTag`	`ActionTag`

The deprecated /tasks operations reference the renamed components, so a regenerated client loses its Task type even if you keep calling the old routes. Rename on your side when you regenerate; nothing else about those responses changed.

When the old endpoints go away

They will not be removed without notice. We will contact affected workspaces directly before any removal, and there is no removal date today.

Mutation payloads

Expressions