API changelog

Unsupported workflow expression scopes are now rejected

Type: Breaking, Bug fix

Affected endpoints: POST /workflows/{workflow_id}/versions/{version}/publish

HTTP status changes: New 409 Conflict when validation findings exist.

The ${input.*}, ${inputs.*}, and ${variables.*} expressions are no longer treated as built-in template scopes. These expressions previously passed workflow validation even though automation orchestrator did not register those namespaces at runtime, so the affected workflow failed when it ran.

Workflow versions are revalidated whenever they are published, including when an existing unedited version is published again. A workflow that contains one of these unsupported expressions now receives an HTTP 409 Conflict response during publish. Versions that are already published continue to run.

Remediation:

• Use ${trigger.*} to read the manual-trigger payload. For output produced by another workflow node, reference that node's actual ID.
• Already-published versions continue to run. There is no grandfathering by creation date or schema version.

(AAP-87176)

Workflows, versions, and executions now use hard deletion

Type: Breaking, Enhancement

Affected endpoints: GET /workflows, POST /workflows, GET /workflows/{workflow_id}, PATCH /workflows/{workflow_id}, GET /workflows/{workflow_id}/versions, GET /workflows/{workflow_id}/versions/{version}, PATCH /workflows/{workflow_id}/versions/{version}, POST /workflows/{workflow_id}/versions/{version}/publish, POST /workflows/{workflow_id}/versions/{version}/restore, POST /workflows/{workflow_id}/test, POST /workflows/{workflow_id}/unpublish, GET /executions, POST /executions, GET /executions/{execution_id}, POST /executions/{execution_id}/retry, GET /projects/{project_id}/workflows

HTTP status changes: None (delete still returns 204).

Deleting a workflow permanently removes the workflow, all of its versions, and all executions associated with those versions. These records are removed rather than being marked as deleted, and they cannot be restored through automation orchestrator. The upgrade migration also purges records that were already soft-deleted.

Workflow, workflow-version, and execution API responses no longer include the deletion-related fields deleted_at and deleted_by. API clients that read or model those fields must be updated.

Remediation:

• Stop reading deleted_at and deleted_by from workflow, version, and execution responses.
• Update any automation or integration that depended on soft-deleted data being queryable before you upgrade. Soft-deleted rows are purged during migration.
• Before deleting a workflow, export any workflow structure that you need to preserve and capture any execution history required for reporting or auditing. A workflow export contains one version's node, trigger, and edge structure. Importing that file creates a new workflow with a new ID and version history; it does not restore the original workflow, its other versions, or its execution records.
• There is no undo for deletions after upgrade.

(AAP-72954)

created_by and updated_by become UserReference objects across all endpoints

Type: Breaking, Enhancement

Affected endpoints: All endpoints that return created_by / updated_by, including workflows, executions, integrations, tools, groups, service accounts, identity providers, and credential workflow associations.

HTTP status changes: None.

The created_by and updated_by fields on all API resources are standardized as UserReference objects ({ id, name }) or null, replacing the previous UUID string format. Previously, three incompatible formats existed: bare UUID strings, plain username strings, and { id, name } objects (only on credentials). This change unifies them.

Remediation:

• Read created_by.id and created_by.name (and the same for updated_by) instead of treating the field as a bare string.
• Update any client code or generated types that expect created_by to be a UUID string.
• Regenerate any auto-generated API client types.

(AAP-90563)

Deleting an in-use credential now returns HTTP 409

Type: Breaking, Bug fix

Affected endpoints: DELETE /api/v1/credentials/{id}

HTTP status changes: 204 No Content to 409 Conflict when the credential is referenced by an integration.

DELETE /api/v1/credentials/{id} now returns 409 Conflict with the error code CREDENTIAL_IN_USE when the credential is still configured as an integration's management credential. Previously, the request returned HTTP 204 and silently removed the credential, which left the integration unable to authenticate. Deleting an unreferenced credential continues to return 204.

Remediation:

• Update clients that delete credentials to handle 409 Conflict responses.
• Reassign or remove the credential from every integration that references it, then retry the deletion.

(AAP-87778)

Service-account credential maximum lifetime is now a runtime setting

Type: Breaking

Affected endpoints: GET /settings, PATCH /settings

HTTP status changes: None.

The APP_SA_CREDENTIAL_MAX_LIFETIME_DAYS environment variable is no longer used. The maximum lifetime for service-account credentials is now controlled by the service_accounts.credential_max_lifetime_days runtime setting, which administrators can change through the Settings page or API without restarting automation orchestrator. The default is 180 days; a value of 0 means the credential never expires. Changes take effect on the next credential create or renewal.

An existing value set through APP_SA_CREDENTIAL_MAX_LIFETIME_DAYS is not migrated automatically. After upgrading, new or rotated service-account credentials use the runtime setting instead.

Remediation:

• Before creating or rotating service-account credentials after the upgrade, verify service_accounts.credential_max_lifetime_days in automation orchestrator settings.
• Set it to the value required by your organization. A value from the former environment variable must be copied manually.

(AAP-87804)

User and group deletion is now permanent

Type: Breaking, Enhancement

Affected endpoints: DELETE /users/{id}, DELETE /groups/{id}

HTTP status changes: None (delete still returns 204).

DELETE /users/{id} and DELETE /groups/{id} now permanently remove the record. Users and groups are no longer soft-deleted, and a deleted user or group cannot be restored through automation orchestrator.

Deleting a user cascades to that user's user-scoped data: group and identity-provider group memberships, identities, sessions, approver rows, and token configurations. Owned resources are not deleted. Workflows, projects, credentials, and executions survive because their created_by and updated_by fields reference principals.id rather than the user record. The user's token_usage_records.user_id value is set to null, so install-wide spend history is retained after the user is removed. If the deleted user created any groups, groups.created_by is set to null so those groups outlive their creator.

The upgrade migration purges users and groups that were previously soft-deleted, and removes the deleted_at and deleted_by columns from both tables.

Remediation:

• Treat user and group deletion as irreversible. Export anything you need before deleting.
• Update any automation or integration that depended on soft-deleted users or groups being queryable before you upgrade. Soft-deleted rows are purged during migration.
• Stop reading deleted_at and deleted_by from user and group responses.
• There is no undo for deletions after upgrade.

(AAP-72954)

Approval API responses now include prompt and loop iteration path

Type: Enhancement

Affected endpoints: GET /approvals, GET /approvals/{approval_id}

HTTP status changes: None.

Approval API responses now include the configured approval prompt field and loop_iteration_path. API clients can display the prompt supplied by the workflow author for an approval request and distinguish repeated approval node iterations in loops. The API change is additive.

Remediation:

• No client changes are required. The new fields are additive.
• Optionally, read prompt to display the author-supplied prompt and loop_iteration_path to distinguish repeated approval iterations inside loops.

(AAP-87735)

Workflow import succeeds when the LLM model is unavailable

Type: Enhancement

Affected endpoints: POST /workflows (with the is_import flag)

HTTP status changes: 422 Unprocessable Entity to 201 Created (draft with warnings).

Importing a workflow no longer fails when the target instance lacks a matching LLM provider configuration. The import clears the unavailable model reference and creates a draft workflow with warnings, so you can reconfigure the LLM provider after import.

Remediation:

• No client changes are required.
• After import, reconfigure the LLM provider on the draft workflow and resolve the import warnings before publishing.

(AAP-87781)

The Ansible Automation Platform proxy resolves the integration without explicit query IDs

Type: Enhancement

Affected endpoints: GET /api/v1/aap/* (Ansible Automation Platform proxy browse)

HTTP status changes: Requests that previously returned 503 return 200 when exactly one visible enabled integration exists.

When exactly one visible enabled Ansible Automation Platform integration exists, proxy browse requests can omit the integration_id and credential_id query parameters. The proxy resolves the unique integration and its management credential automatically. When multiple visible integrations exist, clients must continue to pass integration_id.

Remediation:

• No client changes are required.
• To rely on automatic resolution, ensure exactly one visible enabled integration exists; otherwise continue to pass integration_id.

(AAP-87713)

Files can be deleted; orphaned file metadata is flagged

Type: Enhancement

Affected endpoints: New: DELETE /files/{file_id}; modified: file GET responses add is_project_deleted.

HTTP status changes: New 204 No Content on successful delete.

You can now delete uploaded context files through the Files API. File metadata responses also include an is_project_deleted flag to identify files whose parent project has been deleted.

Remediation:

• No client changes are required for existing calls.
• Optionally, use DELETE /files/{file_id} to remove uploaded context files, and read is_project_deleted to identify orphaned file metadata.

(AAP-86876)

Credential workflow-association responses include created_at

Type: Enhancement

Affected endpoints: GET /credentials/{credential_id}/workflows

HTTP status changes: None.

Credential workflow-association API responses now include a created_at timestamp, so you can see when each workflow that uses a credential was created. The field is returned on the CredentialWorkflowRef response object.

Remediation:

• No client changes are required. The new field is additive.

(AAP-84205)

Task-agent response metadata no longer returns duplicated scalars

Type: Bug fix

Affected endpoints: GET /executions/{execution_id}

HTTP status changes: None.

Task-agent response metadata now returns each finish reason once. Clients no longer receive duplicated scalar values such as stopstop.

Remediation:

• No client changes are required.

(AAP-87759)

Unpublishing a workflow no longer risks a gateway timeout

Type: Bug fix

Affected endpoints: POST /workflows/{workflow_id}/unpublish

HTTP status changes: Eliminates spurious 504 Gateway Timeout.

Unpublishing a workflow now completes without waiting for background cleanup to finish, which prevents avoidable gateway timeouts. Cleanup continues safely in the background.

Remediation:

• No client changes are required.

(AAP-87692)

Agentic node timeout is now enforced

Type: Bug fix

Affected endpoints: GET /executions/{execution_id}

HTTP status changes: None (execution finishes as timed_out instead of running indefinitely).

Agentic workflow nodes now enforce their configured timeout and cancel work when that timeout expires. Workflows that previously ran past the configured limit now finish as timed out.

Remediation:

• No client changes are required.
• Review agentic step timeout values if workflows now finish as timed out that previously ran past the limit.

(AAP-87666)

Approval inside a loop no longer fails on the second iteration

Type: Bug fix

Affected endpoints: GET /approvals, GET /approvals/{approval_id}

HTTP status changes: Second-iteration approval no longer returns 409 Conflict.

Approval nodes inside loops now generate unique identifiers per iteration, which prevents HTTP 409 Conflict errors on the second and subsequent iterations. Approval API responses include loop_iteration_path and temporal_activity_id so clients can distinguish repeated instances of the same approval node.

Remediation:

• No client changes are required.

(AAP-87702)

The Create user API accepts a blank first name

Type: Bug fix

Affected endpoints: POST /users

HTTP status changes: Requests with an empty or null first_name no longer return 422; they now return 201.

The Create user API now accepts an omitted, empty, or null first name and creates the user successfully. Existing clients remain compatible.

Remediation:

• No client changes are required.

(AAP-86107)

Approval fallback-decision validation now respects the system default

Type: Bug fix

Affected endpoints: POST /workflows, PATCH /workflows/{workflow_id}/versions/{version}, POST /workflows/{workflow_id}/versions/{version}/publish, POST /validate (validation findings in the response)

HTTP status changes: None.

Approval fallback-decision validation now resolves the effective continue_on_failure setting the same way the runtime engine does: node explicit value, then system default, then false. Previously, the validation warning checked only the node-level continue_on_failure setting and ignored the administrator's system default. When an approval node was set to follow the system default and that default enabled continue_on_failure, the validation raised a warning incorrectly. Affected workflows no longer receive that false warning.

Remediation:

• No client changes are required. Validation findings are more accurate; workflows that follow the system default are no longer flagged incorrectly.

(AAP-88713)