Portal Community

Output Ports

PortTriggered When
success The operation completed. For read operations this includes "not found" results that are semantically valid — e.g. object/exists returning exists: false is a success, not an error.
error The operation failed — validation error, credential/connection error, or a raw AWS/S3-compatible SDK error. errorCode and errorMessage describe the cause. See the error model below.
cancelled The operation was cancelled or timed out mid-flight. Routed to a dedicated port (distinct from error) so workflow authors can wire different downstream handling for "interrupted" versus "failed." Carries errorCode: "CANCELLED".

Common Output Fields

Every operation's output includes these four fields, plus operation-specific fields documented on that operation's own page:

FieldTypeDescription
statusstringsuccess or error.
errorCodestringEmpty on success; populated on failure (e.g. INVALID_BUCKET_NAME).
resourcestringbucket | object | folder.
operationstringMatches the executor route, e.g. upload.

Tenant-Prefix Effective-Key Model

Every object key, folder path, and search/list prefix is rewritten to live under tenants/{tenantId}/ before being sent to S3. This applies to 10 of the 13 operations — everything except bucket/create, bucket/delete, and bucket/list-all, which act on the bucket itself rather than a key inside it.

Field you typeWhat S3 actually sees
invoices/2026/hello.txttenants/<tenant-id>/invoices/2026/hello.txt

Both forms are always present in the output of a tenant-scoped operation:

Fail-closed: if no tenant is present in the execution context, every tenant-scoped operation aborts with errorCode: "MISSING_TENANT_CONTEXT" before any S3 call is made — it never falls back to writing an unprefixed key.

Per-Operation Output Schemas

Each operation's full output field list, with types and descriptions, lives on its own page:

ResourceOperations
bucketcreate, delete, list-all, search
objectupload, download, copy, delete, get-many, exists
foldercreate, delete, get-many

Error Propagation Model

Three layers, checked in order:

  1. Design-time / node-level validation — required fields and format rules (bucket name, object key, region, KMS key, max keys) fail before any network call. See Configuration for the rules.
  2. Custom pre-checks — e.g. bucket/delete's Verify Empty probe returns a custom error before ever calling AWS's own delete.
  3. Raw AWS / S3-compatible SDK errors — surfaced as-is via errorCode using the backend's own error strings (NoSuchBucket, AccessDenied, NoSuchKey, etc.), or a generic fallback code for anything else the SDK throws.

Each operation's own page lists the specific codes it can return, under "Validation Errors."

Chaining pattern: Because download always carries raw bytes on its data output (independent of its dataMode display setting), the most common chain in this node is object/downloadobject/upload with zero re-encoding in between — see object/download for details.