API keys for backends and workflows

A private workflow needs an authorized caller. Creating an API key does not automatically grant access to every workflow or make a workflow public.

1. Open System Explorer → Keys & secrets → API keys and select Create API key.
2. Choose a descriptive name and an expiration appropriate to the integration. Review the settings before selecting Create and save credential.
3. Use the saved credential through its supported secret reference or credential configuration. Do not paste it into an AI conversation or commit it to source control.
4. Review the key’s Groups and the target workflow’s Manage access settings. Grant the integration’s group the permission needed to invoke that workflow.
5. Confirm that the workflow and key belong to the intended project and factory, and that the key is active.

Default factory keys join the factory API-key group with the supported storage and factory-workflow grants. Published private workflows can use that default-key access; a custom group needs its own Execute and Deep read grants. The key does not publish a draft, override a revoked grant or authorize unrelated resources. Review the actual group and published version.

1. Open the workflow’s More actions → API & schemas and copy the actual endpoint. Read its method, input schema, and published version.
2. Configure the server-side caller with that endpoint and the API-key authentication required by the endpoint’s current API instructions. Use the documented header and format; do not place the key in a URL or infer a header from an unrelated provider.
3. Send harmless input that matches the workflow schema. Test against a destination that will not send real notifications or modify important records.
4. Inspect both the HTTP response and the corresponding workflow run. For asynchronous execution, follow the run status until it completes or fails.
5. Verify that a request without the credential or without the required group access is rejected when the workflow should be private.

A backend can bind its service key to call the direct project-storage API for signing, listing and deletion. It must derive each permitted path from the verified app user and enforce ownership before issuing a signed URL. Never send the service key to the browser. See File storage contracts.

Expiry is checked on every request. Expired and revoked keys remain listed for reference but cannot authorize new requests. To rotate a key, configure and test its replacement in every dependent caller before revoking the old key. Avoid blindly retrying a request that may already have caused a side effect.