Running & Debugging

Run a workflow on demand, follow execution live, and diagnose problems from per-node output and logs.

Review validation problems

Use Validation above the canvas to see errors and warnings without opening Resources. Nodes with missing credentials or unsupported imported connectors show a warning icon and a colored outline; invalid Claude Code or Codex CLI model settings show an error marker. Open node selects and centers the affected node and opens its configuration. It keeps nodes distinct even when their names match. The Resolve issue action in an error banner uses the same navigation. Workflow-wide issues open the editor when no specific node applies. Fix the configuration and refresh validation to update the markers. If validation cannot complete, its status shows Failed rather than Ready. Open Validation to see the error and use Refresh to retry; Not checked means no validation report is available yet.

Running a workflow

For workflows using Versions & previews, select Production or a named preview above the editor. The selector shows its deployed version and whether it is On, Off, Blocked, or Stopping. Opening a workflow with configured destinations selects production by default; a link to a preview keeps that preview selected. Selecting a destination never starts an execution. The canvas stays in its loading state until the destination summary is ready, so blocks do not move under the pointer while you start editing.

• Dry-run candidate simulates the selected destination's saved candidate. Its execution record includes the destination even when it shares a version with another preview.
• Run deployed version uses that destination's approved live activation and selected connections. It is unavailable while the destination is off. It can change real data and consume credits.
• Manage versions lets you name a saved workflow version or create a named preview from it. A name changes presentation; the immutable version number, content and approvals stay the same.

The legacy editor, for workflows that have not set up previews, retains these actions:

Open Editor → Resources for workflow test input and validation. Node settings stay in Edit.

From the Editor:

• Dry-run candidate — the primary test action. It pins the newest saved candidate version, completes inline even when Redis is enabled (queued: false), simulates effects, and records requestedTarget: "candidate", the versionId, resourceMode: "simulated", and reviewIdentity.
• Run candidate live — requires an explicit confirmation bound to the expected candidate version. It uses real workspace credentials and external systems (resourceMode: "workspace-live"). This is not a separate or runtime-isolated environment.
• Run from a block — start at startNodeId. When a prior run is still current, upstream outputs can be reused; if stale, dependencies re-run.

Before confirming Run candidate live, review the saved actions, selected accounts and manual input. For native API connectors, that confirmation authorizes the saved workflow's dataflow for this one run. Expressions can use results from earlier blocks; their final targets and values are determined during execution. Required privacy and effect acknowledgements on each block remain separate requirements. The confirmation is tied to the version, input, execution segment and selected account values. Changing one requires a new confirmed run. Confirmed native runs require plain JSON input and seeds, at most 256 levels deep; negative-zero numbers, undefined values and typed objects such as dates are rejected rather than changed during persistence. A queued execution uses its persisted confirmation and rechecks the actor, account and live-execution setting before dispatch. It does not grant later runs, Agent calls, automated triggers, end-user runs or named deployment targets permission to bypass their own checks.

When that run pauses at a Wait block, its continuation keeps the confirmed version, original input, selected accounts and original stopping point. The server uses the persisted checkpoint to authorize the next segment; completed upstream actions are not repeated. Account rotation, lost execution access or a disabled live setting stops subsequent connector calls. Review the failed run before starting and confirming a new one: actions already sent to an external service are not undone.

Programmatic: POST /api/v1/workflows/{id}/execute with a workspace-scoped API key (403 otherwise). Public execution targets the active version by default. Body: input?, startNodeId?, dryRun?, target?, executionTargetId?, expectedVersionId?, confirm?. Idempotency-Key supported. Returns { run, execution, queued, statusUrl, cancelUrl } — 202 when queued to BullMQ, 201 when inline. Default input is { prompt: "API execution" }. Invalid JSON body, or a body that is not a JSON object (such as null or an array) → 400.

Pass executionTargetId to select a preview or production destination explicitly. Live runs pin its approved activation; target: "candidate", dryRun: true simulates that destination's prepared version. The typed workflows.execute tool accepts the same destination. Retrying an idempotency key with a different destination, activation or API principal is rejected; an inaccessible destination never falls back to production.

Candidate execution defaults to dry run. A live candidate request must send target: "candidate", dryRun: false, confirm: true, and the current expectedVersionId; stale versions fail closed. Active v1 continues serving production while candidate v2 is tested, reviewed, and synchronized. Only an explicit deploy changes the active version.

tRPC workflows.run (session) targets the candidate by default and also accepts executionTargetId, executeNodeId, executeDependencies, sourceRunId, target, expectedVersionId, confirm, and trigger (manual | webhook | schedule | copilot | api | email | rss). A source execution must belong to the same workflow and destination. A named destination uses its approved activation for live execution; live candidate requests cannot bypass its publication checks.

Receive and use files

Choose the entry that matches the sender:

1. Shared form: add Form Trigger, then add a File input called documento. Choose required, single/multiple and accepted extensions, such as .pdf,.csv. Access defaults to workspace members. To allow visitors, explicitly select Anyone with the link. Publish the saved version and open Open production form in its block settings. Changing the candidate does not change that form.
2. HTTP sender: add Webhook and send multipart files to its deployed URL. For example, curl -F 'adjuntos[]=@report.csv' -F 'comment=Monthly report' "$WEBHOOK_URL". For a raw file, select Raw binary body and send the bytes with the file's content type. JSON and text bytes require that option to become a file; otherwise they use the regular payload path. Temporary file listeners apply the same rules and reject unsupported bodies without consuming the listener. Multipart files work with either setting.
3. Editor: add a File input to Start. In Editor → Resources → Manual run, upload a file or select a ready Workspace File. Load more files reveals older files when the first page is full. If one upload in a batch fails, successful files remain selected; the error names each failed file so you can select only those files to retry. Only selected files awaiting a scan are polled, for up to two minutes after their last update; abandoned metadata records do not keep the picker polling. Remove clears the selection without deleting the shared file. The selection belongs to this workflow's next run; saving the block stores its field definition. Executing a downstream step with previous nodes uses the connected Start's selected files too.

Add Extract from File after the entry. Set its dataPropertyName to the key in the entry's Binary tab (documento, documento_0, adjuntos0 or data, depending on the entry), and choose fileFormat. The extractor inspector displays its rows and text output. Open rows in JSON or expand its Table cell to inspect individual records. Text extraction displays the text field. Inspection and pinned data preserve the runtime/API item structure. CSV extraction also works in a candidate simulation. Invalid quoting or inconsistent column counts fail extraction instead of passing partial rows downstream. CSV processing is limited to 16 MiB, 10,000 data rows and 200 columns. Plain text also has a 16 MiB processing limit; XLSX and field/output budgets also fail with an extraction-limit error. Split or reduce the file before retrying. A live HTTP Request can send a file as Binary file or Multipart files. Existing egress and credential checks still apply; product connections that cannot sign a file body reject the send.

For Form or Webhook, Listen for test workflow or Listen for test step creates a separate, single-submission URL for 120 seconds. After an accepted test submission, create another listener for a new submission. Save the candidate first. Open test form opens the temporary form; Webhook senders POST to the displayed test endpoint. The listener shows its state and test run ID, whose output is available in execution history. Test execution uses simulation and does not deploy the candidate. Expiry stops new submissions, while an already received submission can finish scanning. Canceling before dispatch also rejects an accepted submission that is still being scanned. Test Webhooks retain safe custom headers and query parameters, with credentials and capability tokens removed. Start another listener after expiry, cancellation or use. An invalid upload can be corrected on the same listener until its original expiry; acceptance consumes it.

New files are stored and scanned before any downstream node runs. An HTTP 202 returns a private receiptUrl; the form polls it automatically. pending_scan means scanning has not completed, dispatched means the submission reached execution dispatch, and rejected or expired means it did not. Acceptance does not mean the workflow finished. Do not share receipt or entry links as ordinary file-download URLs: downloads require workspace authorization.

Integration actions that store Workspace Files return a reference only after the file passes its security scan. A failed or cancelled write requests cleanup of its new file and run reference; cleanup can remain pending if storage is unavailable. File reads honor Stop while receiving bytes and reject content whose size or checksum differs from the stored file metadata.

Limits are 10 files, 100 MiB per file and 100 MiB total, plus 1 MiB of text and 2 MiB of multipart framing. Reused files, retained upstream outputs and new Start selections share the total input budget. Node configuration can reduce file limits. An incoming Form/Webhook body must finish within five minutes; 408 means the upload was aborted and must be started again. Two ingress uploads may be active per workspace; public entries allow 30 attempts per minute per endpoint. 429 includes Retry-After. Required-field, extension or malformed-body errors need a corrected submission. A pending scan is retried by the worker; Files unavailability returns 503. Reusing the same submission identity with different files, fields, query parameters or business headers returns 409. Stopping the destination prevents new submissions.

Publish, promote and stop a preview

1. Open Manage versions, select a saved version and choose Create preview. Give it a name. The preview starts off.
2. Choose its connections explicitly and save them. Sharing a production account can change production data, even though the preview has a separate webhook URL. Choose an exact child deployment for each called workflow; stopping a child blocks dependent executions.
3. Prepare its AIMS request. Open approvals keeps the workflow and destination selected. A preview approval does not authorize production. Current roles, independent review and recent MFA still apply.
4. The eligible reviewer chooses Approve and enable, which publishes if connections, AIMS and repository requirements pass. Check On and the expected deployed version; do not deploy again. If approval was saved but publication was blocked, resolve the displayed requirement and use Retry enabling. Deploy version also lets an authorized operator publish an already approved version from the editor. With no linked repository, Git is not required; a linked preview needs the exact reviewed commit and production requires its merge. Publication turns on enabled trigger nodes; explicitly disabled nodes stay disabled. Updating a preview preserves its existing webhook URL.
5. From a deployed preview, choose Promote to production. Decide whether to switch off the source after publication; this is selected by default. Review production's own connections and AIMS request. The production reviewer uses Approve and enable for this separate request. Production keeps serving its current version while review is pending. Successful promotion changes production and applies the selected source-stop choice together. Keeping the source on leaves both destinations enabled, with separate webhook URLs.

Use the destination switch to stop it, or open Workflows → Active deployments to find and switch off destinations across workflows. On means it can accept events, even with zero executions. Blocked means its deployment cannot currently pass an authority or connection check. Stopping means new events are blocked while queued, running or waiting executions are being canceled. Effects already sent to an external provider may finish. Switching on requires a successful publication check; a failed request does not display a successful activation.

Production's Previous deployments list offers Restore deployment for snapshots whose AIMS grant explicitly permitted future production reactivation. The original grant must still be valid and its connections and dependencies available. Restoration creates a new activation from that exact snapshot, preserves production's URL, and cancels the replaced generation. It does not restore or undo external data. An old deployment without this permission offers Prepare rollback approval. It copies the historical version and connection references into a separate rollback request while the current deployment and editor candidate stay unchanged. Complete the new AIMS review, then publish. Request new approval provides the same recovery path when a previous reactivation grant expired or was revoked. Current connection and Git checks still apply.

Moving a workflow to the trash stops all its destinations and requests cancellation of pending executions. Restoring it from the trash leaves those destinations off. Changing destinations, leaving for Approvals, reloading, or using browser Back/Forward warns before discarding unsaved editor changes.

The former environment promotion screen is retained as history, rather than a second publication flow.

Poll GET /api/v1/workflows/{id}/status?runId= until a terminal status. pollAfterMs is 1000 while active, null when finished. Without runId, the handler returns the workflow plus up to 20 recent runs.

Run status

waiting is not finished. Timer/event/approval detail lives on the runtime checkpoint, not on the v1 status string. GET /api/v1/runs can filter status=waiting. Cancel is allowed on queued / running (409 otherwise); a parked waiting run is not canceled by that endpoint.

For Claude Code and Codex CLI calls, cancellation stops the CLI and, where supported, its child processes. Waiting for remaining output is bounded, including output kept open by helpers. Available usage is retained; missing measurements remain unknown. Final accounting and run-state updates can still take time, and cancellation does not undo effects already sent.

Ordinary fan-out processes its destinations in order. Pending destinations remain selected across a durable Wait or Jenkins build wait; completed destinations are not repeated on resume. A Parallel block in the Logic category provides an explicit way to run two or more independent I/O branches concurrently. Results follow the connected branch order, and branch outputs remain isolated from one another. Connect branch ends to one common downstream block to join them; it waits for all branches and can reference their outputs. A branch paused at a durable Wait or Human Task checkpoints completed siblings, which are not repeated on resume. Jenkins Trigger build and wait for result is not supported inside Parallel.

Parallel fail-fast behavior stops a failed branch from taking further steps and waits for operations already in flight; it cannot cancel side effects already sent. Collect-errors runs every branch and reports errors, but a failed branch prevents the common downstream block from running. Parallel coordinates workflow steps and does not promise simultaneous CPU execution of function code. You can use it below either Condition output when that route needs concurrent fan-out. Workspace subscription calls to the same CLI kind remain serialized by the credential lease that protects OAuth refresh; Parallel does not remove that protection.

A fatal Claude Code or Codex reported-model mismatch fails the run without an automatic queue retry. Parallel stops further steps in every branch and drains operations already in flight, including with collect-errors. Completed steps, including steps before an exception in the failing branch, remain in the failed run's execution history. A reported-model mismatch takes priority over other branch interruptions, so those interruptions cannot make it eligible for an automatic retry. Review the recorded external actions before starting a new run; starting again can repeat those actions. If a temporary database failure prevents the run from being marked failed, the worker retries closing the run without restarting its nodes. Other completion work is still attempted after a completion error; schedule and end-user turn reconciliation repair their pending records. If the database was unavailable during terminal persistence, some step history may be missing; check the external service before starting a new run.

Queue vs direct and leases: Workers and recovery.

A Confluye GitHub review fails validation

A completed reviewer process can still produce an invalid review. If you have access to run content, check the run error and final output for reviewFailure: its stage, reason code, and issues identify the rejected schema fields without copying findings, credentials or process output. The GitHub failure notice reports the same safe cause when the reviewed commit is still current and publication is authorized. A failed or stale notice publication does not turn the review into a success.

Finding severity uses critical, high, medium or low. The trusted review runtime maps only the known priority labels p0, p1, p2 and p3 to those severities. Unknown labels and non-string values remain invalid. For example, validation_failed with findings[0].severity and unsupported_severity means the completed review was blocked at validation; no findings were published. Correct the field before retrying. Secret, location, complete-context and publication checks remain required. This normalization also applies to existing trusted review workflows after the updated runtime is deployed; it does not edit their saved configuration or repair historical runs.

Executing one step

Session POST /api/workflows/{id}/execute-step (Member+). Body: { nodeId, sourceRunId?, executionTargetId?, expectedVersion?, allowRealEffects? }. Set executionTargetId to the selected preview or production destination; live execution requires expectedVersion for its approved deployed version. Trigger nodes cannot run this way. Seeds come from the chosen source run, else the latest run with outputs for direct dependencies. Pinned output wins over run output.

In the inspector, Execute step tests the saved candidate with simulated effects. Run deployed step uses the selected destination's approved deployed version, even when the editor has a newer candidate; its confirmation names the destination and version. That confirmation also authorizes protected connector operations in the selected step, such as clearing Sheets values or replacing Slides text. It does not authorize other nodes, Agent tool calls or later workflow runs. It requires Admin or Owner execution access and recent MFA, and is unavailable while the destination is off or if the node is absent from the deployment. If MFA expires, verify in the dialog and confirm the destination and version again; verification does not run the step automatically. Viewers can inspect the workflow but cannot edit, simulate, publish or run it. Live effects require allowRealEffects: true. Successful executions write an audit event (node, source run, effect classification/mode, pin ids, live flag).

There is no v1 execute-step route.

A simulated single step can use a saved version and compatible upstream pin even when that provider's live transport is disabled. The selected node records a simulated result without contacting its provider or enabling the transport. If missing pins or stale run data require upstream refresh, those upstream nodes retain normal transport checks and execution; the whole graph is not guaranteed to avoid provider requests. Workflow structure, input schemas and selected-account scope still apply. Version matching and pin freshness are checked separately: a matching saved version does not validate an outdated pin. A live step still requires the destination, permissions, confirmation and live provider readiness described above.

Prepared Google verification cases

An operator-prepared Google Sheets or Slides case can explicitly authorize its protected actions in the saved version submitted for AIMS approval. A current approval for that exact version is required each time the action runs. The request must match that version's literal inputs. Caller-controlled expressions are rejected; resource IDs can refer only to live Google creation results from the same execution and credential. Revocation, expiry or supersession stops subsequent actions. This option does not confirm Agent tool calls, end-user runs or named deployment targets. Other workflows retain their existing confirmation requirements.

Pinning data

Session GET|PUT|DELETE /api/workflows/{id}/pin-data (Member+). GET/DELETE: ?nodeId=&executionTargetId=. PUT: { nodeId, items, executionTargetId?, expectedVersion? } (array or object). Omitting the destination selects the legacy Production namespace. 413 if over 256 KB. 422 if items is neither array nor object.

Pins belong to the selected destination. Two previews made from the same workflow version have separate pins; creating a preview does not copy Production's test data. The inspector and workflows.prepare-test-data use the same destination scope. Removing a node clears only that destination's pins, and step execution cannot use another destination's pins or source runs.

Pins are fixtures, not a cache. The inspector shows Pinned or May be outdated when node config drifted. Secret-like values store as redacted. Pins expire after 30 days (FLUXUS_PIN_DATA_RETENTION_DAYS; 0 disables the sweeper). The worker tick deletes expired pins.

Inspecting a run

Execution-detail loading and errors follow the execution you selected. A retained Copilot execution may show its own retrieval notice with Retry while another manual execution remains selected and successful. Retrying that lookup reads the existing record; it does not start another workflow execution. Newly completed step output stays visible when an earlier history refresh arrives late.

Live node badges, duration, and output preview. Inspector: input, output, request, response (secrets redacted). Logs terminal streams the active run. Run selector: Run N of M. Multi-item output: item selector plus Table view.

Opening a past run displays its Execution snapshot · read-only. Choose Copy to editor in the execution banner or node inspector to return to the current editable workflow with that run's inputs and step outputs. Expression previews use the chosen run rather than the newest run. Copying does not execute nodes, send messages, launch builds, restore an old graph, or save changes.

Only steps whose node IDs and types still match the editor are copied. The Copied execution data banner names the source run and counts compatible steps. Copied output takes precedence over pinned fixtures for inspection; the fixtures remain saved, and an explicitly requested Execute step still uses the normal pin precedence described above. Clear copied data removes this temporary context. It also clears when leaving this workflow or destination or reloading the page. Member edit access is required, and data cannot be copied between destinations.

When executing a step with copied data, removed or retyped nodes cannot supply historical output. If compatible upstream data is missing, execution stops with an error; prepare current test data or explicitly execute previous nodes. Copying never reruns those dependencies automatically.

Events: session GET /api/runs/{id}/events (SSE, Last-Event-Id reconnect). Full history: Executions and /api/v1/runs.

Expression preview (canvas): session POST /api/workflows/{id}/evaluate-expression (rate-limited, size-capped). Not on v1.

Node execution flags

Stored on node settings (including n8n import):

These apply to normal runs, re-runs, and single-step executions.

Debugging failures

Embeddings, image generation, audio, direct web search and Google AI errors show the provider's HTTP status, readable message and available type, code or status identifiers. For example, 429 (insufficient_quota) preserves the provider's quota diagnosis and billing link instead of showing a cut-off JSON response. Error details are limited to 500 characters; a URL that cannot fit is omitted rather than cut in half. Request headers and credential values are not appended to the message.

• Fix and re-run from the failing block (seeded outputs).
• POST /api/v1/runs/{id}/rerun — new run, original input (201).
• Resume waits: timer sweep / resume hook / approval API.
• Workflow Copilot can read the last run.

If the run never left queued, treat it as a worker/Redis problem, not a node bug.

Parked Human Tasks and Agent approvals

A run parked at a Human Task (approval) or a pending Agent tool approval shows waiting. It holds no live worker and its compute segment is closed while asleep, so it neither reserves nor bills compute until it resumes. Find the work in the Tasks inbox or the run detail's task card, which show the safe reason, the relevant policy/version identifiers, and the allowed action. An Agent tool proposal is immutable — approve executes the exact hashed proposal after a fresh guardrail and authority recheck; rejecting with feedback creates a new proposal rather than editing the pending one. For detection, diagnosis, and safe recovery of parked, orphaned, racing, or lost-signal states, see the Human Task recovery runbook.

Next steps

For an AI node in a named destination, set its provider endpoint and model in the candidate graph before review. The selected credential supplies secret bytes. A URL or API-version field stored inside credential JSON cannot override the approved graph when that destination runs. Rotations are checked again at dispatch; if a connection changes during a node, retry with the current connection.

Home Assistant read limits

Home Assistant reads require the selected native account and explicit workspace live setting, which overrides the environment fallback. Check the editable personal-data acknowledgment, then confirm the checked workflow version and segment separately. A refused format, response bound, secret collision or provider deadline stops the read without an automatic retry. Review the five-read profile before changing inputs. Local callback tests do not prove human consent or durable approved continuation.

Humantic AI request limits

Humantic AI makes one attempt per invocation, including when Retry On Fail is enabled. A creation failure or timeout can leave processing started; inspect provider state before manually starting another request. The selected native account, live setting, both acknowledgments and independent run confirmation are required. Static response or privacy errors refuse the full result without exposing provider diagnostics or the API-key query. See profile setup and limits.

Iterable uncertain writes

Iterable makes one attempt even with Retry On Fail. Events, profile changes, deletion and subscriptions may already have applied after a timeout or failed response; inspect provider state before manually retrying. Region stays with the selected account and never falls back to another endpoint. Iterable setup and limits explains typed IDs, acknowledgments, bounded projections and static errors.

HighLevel uncertain writes

HighLevel makes one attempt despite Retry On Fail. Contact/task/opportunity changes, deletion, upsert and bookings may already have applied after a timeout or rejected response. Inspect provider state before a deliberate retry. Fixed notification flags do not certify absence of all downstream effects; a successful local acknowledgment does not prove durable completion. Setup and limits explains the legacy PIT profile, bounded projections and independent acknowledgments.

Keap bounded action failures

Keap makes one attempt despite Retry On Fail. Unsupported shapes, mismatched actual IDs and body, parser or projection limits reject the entire result rather than returning a truncated page. No returned links are followed. The10-second provider and11-second gateway budgets begin after confirmation and credential preparation; preparation has no deadline. After a write request starts, a failure may leave its outcome indeterminate. Inspect the provider before an explicit manual retry; Stop cannot undo an in-flight effect. Empty202 email acceptance does not prove queuing or delivery, and successful empty204 deletion returns no entity. Keep tokens in saved accounts and inspect Keap limits before changing inputs.

Native API segment recovery

Queued workflows containing enabled native API blocks reserve a single execution segment, including reads. A competing delivery refused for segment ownership receives a busy/reconciliation error before another native request. That refusal cannot release or terminalize the active owner; current authority is checked independently. Changing Retry On Fail, releasing a lease or waiting for expiry does not reopen a claimed segment. A native worker does not automatically take over an existing expired owner. Preparation can fail after reservation without sending HTTP, and a request can finish remotely before local publication fails. Inspect the run and provider state, then make an explicit decision about a new run. There is no automatic reset or reconciliation button, and no external exactly-once guarantee.

A committed timer/event/approval resume identifies a new exact segment and preserves earlier outputs. A stale initial or earlier resume delivery cannot claim that new segment. This continuation is separate from unattended provider authorization or human consent. Native ownership still applies when optional runtime-v2 projection is disabled. Memory ownership disappears with its process; inspect possible external effects before a deliberate new run after restart.

Stop checks the stored run before later native actions, and late completion cannot replace a canceled run. A request already starting or in flight may complete remotely: Stop does not undo a record change or recall a message. Inspect effects before a manual retry. See worker recovery for the general non-native rules and Invoice Ninja limits for financial and email uncertainty.

LinkedIn publication uncertainty

LinkedIn publication makes one attempt even when the block retry setting requests more. The provider budget is ten seconds after credential/local preparation and the gateway budget is eleven seconds after credential preparation; preparation has no deadline. An attempted publication can complete remotely despite a timeout, Stop, rejected response header or local publication failure. Inspect LinkedIn before explicitly deciding whether to repeat it; no automatic retry or readback resolves uncertainty. A returned URN does not prove visibility or media readiness. See LinkedIn limits.

Mandrill send uncertainty

Mandrill makes one send attempt even if a block requests several retries. Provider execution, response reads and projection have a ten-second budget after input/credential preparation; the shared gateway has eleven seconds after credential resolution and preparation has no deadline. A timed-out or stopped send may complete remotely, and a reported sent/queued/scheduled status does not prove delivery or live-key use. Inspect Mailchimp Transactional before explicitly repeating an indeterminate send. No automatic readback or email recall is provided. See Mandrill limits.

LingvaNex and Magento uncertain attempts

Both profiles make one attempt, including reads, even when block Retry On Fail requests more. Provider processing/reading/projection have ten seconds after local preparation; the gateway has eleven seconds after credential preparation and preparation has no deadline. A translation may process text or incur charges, and a Magento effect may finish remotely, despite timeout, Stop or a rejected local result. Inspect the service before intentionally repeating an indeterminate effect. A returned ID, false boolean, selected status or single page does not certify complete data, delivery, payment or merchant state. There is no hidden readback, recall or automatic retry. See LingvaNex and Magento.

Household, messaging, relationship and OCR uncertainty

All47 operations across the six finite profiles make one attempt, including reads, even with Retry On Fail enabled. Provider10s/gateway11s budgets begin after confirmation/credential preparation; preparation has no deadline. A timeout or Stop does not undo household automations, room/membership changes, CRM/reminder scheduling, quota use, document processing or SMS. Reminder writes can schedule EVERY account user, replace outboxes and roll past/today dates forward, including year addition for one_time. Inspect the service and camera Workspace Files before intentionally repeating an uncertain effect. Provider success, billing, delivery and durable/organization execution remain unverified. See specific limits.

Receipt, Calls and Mocean uncertainty

These eight additions make one attempt with provider10s/gateway11s budgets after confirmation/credential preparation, without a preparation deadline. Mindee's1MiB upload limit applies after the shared adapter may read/hash up to100MiB. Calls writes can change associated last_talked_to; deletion detaches call emotion associations and remaining-call ordering is unverified. Mocean can incur charges without proving SMS delivery or a connected voice call. Stop/timeout cannot undo an attempted effect. Inspect the service before deliberately repeating an indeterminate action. See limits and selected outputs.

Mistral and Teams request limits

All nine actions make one attempt with provider10s/gateway11s after confirmation and credential preparation; preparation has no deadline. Mistral can first read/hash up to100MiB through Files before refusing a returned snapshot above1MiB; it sends a copied PDF data URL without the private filename to fixed OCR using a model alias, with no complete-PDF, OCR accuracy, retention or refund guarantee. Teams returns one bounded page and does not follow links, render HTML or prove scopes/membership/licensing. A failed read may reflect local budgets or unsupported continuation spelling. Inspect an uncertain OCR effect before deliberately repeating. See limits and remaining verification.

Activity and Teams mutation uncertainty

All14 actions make one attempt with provider10s/gateway11s after confirmation and saved-credential preparation, without a preparation deadline. Any post-invocation mutation failure is uncertain, even when a received acknowledgment violates the conservative local contract. Activities delete requires a string acknowledgment ID; real remote wire type remains unverified. A Teams204 requires an actual null body and observes only status. Stop cannot guarantee server rollback; inspect effects before deliberately repeating. No hidden read, ETag refresh, retry, full history or durable-state guarantee is added. See the fourteen field and response contracts.

Agent spend and public-query disclosure

Perplexity Agent can execute multiple billable provider research/model/tool steps for one local HTTP request. Stop/timeout does not prove cancellation or avoided charges. OpenThesaurus receives the public query word and metadata, needs no account, and must retain the visible source/copyright/license attribution. Both actions make one attempt with provider10s/gateway11s after preparation/confirmation and no preparation deadline. Saved manual consent is scoped to run/workspace/actor/workflow/version/material/exact operation; public OpenThesaurus consent has zero credential fields and does not authorize another operation. Current native fetch/provider account compatibility and matching-revision Review remain unverified. See the two field, response and privacy contracts.

Mailbox and relationship-data uncertainty

These23 new operations use one attempt at maxTries3, with provider10s/gateway11s after confirmation/credential preparation and no preparation deadline. Unsupported/error mutation responses are uncertain and timeout cannot prove rollback. Outlook selected error/errors records are refused even null; unknown scanned fields are dropped. Contact GET can change consultation/view state. Conversation deletion expects original numeric-ID acknowledgment; contact deletion expects string ID. Local synthetic tests and simulated UI Save do not prove real mailbox/relationship permissions, authenticated successful Save, Prisma organization execution, human consent or matching-revision Review. See the23 field and response contracts.

The next sixteen Outlook writes bring the group to119 actions and Outlook to28 operations. Each makes one attempt even with maxTries3, provider10s/gateway11s after confirmation and credential preparation, and no preparation deadline. Local cancellation/timeout does not prove remote cancellation or rollback. After an uncertain write, inspect remote state before deliberately repeating. Draft send202 means accepted, not delivered; delete204 does not prove retention/recovery. Live Graph wire framing, permissions and matching-revision Review remain unverified. See Outlook write limits.

Scan submission and market-query uncertainty

urlscan submission requests private visibility but discloses the URL to the scanner and visited site, may consume quota and can remain uncertain after transport invocation; inspect before deliberately repeating. scan.get is one manual result read without confirmation/polling. Marketstack reads disclose their query and consume quota, require separate confirmation, and return selected observations rather than freshness or completeness guarantees. All five make one attempt at maxTries3 and recheck account/live state after both callbacks, without atomic remote authorization. urlscan uses a10s gateway timer after preparation; Marketstack provider10s/gateway11s start after confirmation/preparation. There is no preparation deadline. See limits and unverified external behavior.

Run one npm metadata read

Each npm action makes one bounded public GET with no automatic retry/page/download/script execution. Search returns one manually selected page; version dates are actual observations, not SemVer order or freshness. Both dispatch callbacks finish before the final current-authority check; persistence errors never use the legacy local fallback. The provider and gateway each have a10s timer after their preparation boundaries. A simulated callback is not human consent and local Responses are not live registry certification. See the npm field, response, privacy and timing contract.

Taiga and Twake approved results

Every Taiga record request and Twake plugin message requires the original actor's exact-request Human Task approval, valid for 15 minutes, and current workspace and organization authority. An account or request change invalidates pending consent. Each invocation allows one physical attempt even when a block requests retries. After an uncertain outcome, inspect the remote service before deliberately starting another run; Stop cannot undo a sent record change or message.

Before an OUTPUT block receives a result, the runtime checks the settled effect, its approved request and the actual materialized result together. A missing or changed result fails locally without resending the provider request. HTTP success and returned IDs do not establish delivery or verified remote effects. Local tests use simulated provider and database state; these providers' matching Review, real authentication, current composed PostgreSQL durability and native socket behavior remain unverified. See Taiga limits and Twake limits.

Telegram and KoBo approved results

Only the original run actor can approve these exact requests within 15 minutes. The runtime rechecks workspace and organization access, saved credential revision, workflow/version/node/input identity, the completed task and its exact consumed wait. A different approver, changed request or revoked access requires a new approval.

Each invocation permits one physical attempt. After timeout, disconnect, rate-limit response, invalid JSON or an uncertain settlement, the application never automatically resends, refreshes, redirects or reads back. Stop cannot undo a message or mutation already sent. Before deliberately starting a new run, inspect remote state through your normal service account.

A fresh OUTPUT check validates the authenticated settled result against the actual materialized result and current authority. Missing or altered task/wait/effect/result data fails locally without another provider request. Telegram response acceptance does not prove delivery; KoBo deletion acknowledgments and hook retries do not prove deletion or delivery to configured destinations. The Telegram and KoBo guides explain retained raw data and unavailable modes. Local tests use simulated storage and providers; matching-revision Review and real provider/DB/Redis/native-socket/human tests remain pending.

AWS Comprehend, SNS and SES outcomes

Each exact request requires the original actor’s HumanTask approval and current workspace and organization access. The consumed task ID and wait token remain bound through claim, send, settlement and fresh OUTPUT. One checkpoint claim permits at most one physical request; a timeout, disconnect, storage/scanner failure or missing receipt leaves an uncertain outcome and never grants an automatic resend. Exact bounded raw bytes are application-encrypted in WorkspaceFiles and authenticated again when OUTPUT is reconstructed. The scanner sees ciphertext, not plaintext; unavailable protected storage prevents a usable result. HTTP acceptance, MessageId or TopicArn does not prove delivery, processing, verification or remote state. Local simulated tests do not establish real provider permissions, DB/Redis restart behavior, native sockets, storage scanning or Review interaction.

HaloPSA protected outcomes

Approval, physical claim, send, settlement and fresh OUTPUT keep the original task ID and wait token bound to the exact actor, account, workflow and request. Each action requires current workspace and organization access. An uncertain outcome never triggers automatic resend or recovery reads. Bounded raw response/error content is encrypted in workflow checkpoints; public output contains protected cardinality and digests. That content remains while the checkpoint exists, with no promised automatic deletion deadline. Real HaloPSA authentication, notifications, deletion and billing effects, native sockets, durable DB/Redis restart and Review walkthroughs remain unverified by the local simulated tests.

GoToWebinar protected outcomes

Original-actor approval, current workspace AND organization execution rights, selected account/request revisions, original task ID/wait token, one physical claim and the current execution lease remain bound through settlement and freshly reconstructed OUTPUT. An uncertain outcome never authorizes automatic resend or readback. A next page requires its own new approval. Review invitation/cancellation recipients, survey content, deletion scope, notifications, quota and cost separately; HTTP success does not confirm those effects.

Raw provider responses are encrypted in protected Workspace Files. Public output contains authenticated file references, digests and counts; unavailable storage/scanning refuses usable output without repeating the provider request. Scanning is ciphertext-only. Business fields are not directly available for downstream mapping, and no decrypt viewer or automatic retention deadline is added. Authored inputs/source ledgers may remain personal data in ordinary workflow configuration and approval history.

Local tests use simulated storage/provider/native boundaries. Real app entitlement, current authorization scope/token, provider effects, durable DB/Redis restart, native sockets, storage/scanner behavior and Review organization/tutorial walkthroughs remain unverified.

FileMaker single-attempt outcomes

The captured original task ID AND wait token, original run actor, current workspace AND organization execute rights, selected account/live policy, published node/input and winning execution lease remain required through request and fresh output. A durable winning claim permits at most one physical request, including a workflow configured with three retries. Replacing the task on the same wait does not renew consent. Decline or lost authority before claim sends no request.

After timeout, 429, parse error, disconnect, crash or uncertain settlement, do not automatically resend, read back an effect, follow a returned URL or renew the session under the old approval. Even GET/find can run scripts or disclose sensitive records. Review state manually before considering a separately authorized new request. Accepted HTTP/schema results do not verify scripts or remote business effects. Field/portal data and raw source envelopes may remain in ordinary history/checkpoints/exports and downstream AI; this integration supplies no automatic TTL, protected-only viewer, raw-database encryption, scanner or deletion-completion guarantee.

Bitwarden one-attempt outcomes

Only the persisted original actor with current workspace AND organization role/capability may confirm the exact request. Selected account ciphertext revision/live policy, published node/version/input/materialized request, captured original task ID AND wait token, execution lease and authenticated result remain required through fresh output. Replacing the task while retaining a wait token cannot renew consent.

A durable winning claim permits at most one physical send, even with three workflow retries. Timeout, reset, 429, uncertain/lost settlement or lease expiry cannot authorize replay, token refresh, redirects or readback. Do not automatically repeat a delete or membership replacement. Reconcile uncertainty manually before considering a separately authorized new request.

An admitted HTTP 200 or bodyless response does not verify the resulting organization change: outcomeVerified:false remains. Admitted business fields can feed later mapping/routing; names, emails, relationships and event IPs remain ordinary authorized history after acknowledgment. Account secrets are encrypted; this does not add encrypted raw DB history, expiry, scanning or deletion guarantees. Real provider effects, token entitlement/server compatibility, durable restart behavior and Review workspace/organization flows still require independent verification.

Cortex and n8n software Public API execution

An exact-request approval pause has sent zero HTTP. Review the manual IDs, schema-2 migration and each unchecked retention/attempt/page acknowledgment; Named and JSON use the same request. Cortex pending reports and n8n new/running/waiting executions never start polling. A returned nextCursor is inert until a separate request is prepared and confirmed. Audit Generate is an explicit POST.

The original run actor must confirm the exact resolved request with current workspace AND organization execution access. Selected encrypted account revision, published node/version, run input, live-policy generation, original task ID AND wait token and execution lease remain bound through one winning durable claim, settlement and fresh authenticated output. A replaced task never renews consent. One physical attempt is allowed, including workflow maxTries3; timeout, reset, rate limit or an uncertain used claim never triggers automatic resend, readback, redirect or refresh.

Names, IDs, tags, schema option labels, job/report fields and audit locations may contain personal data retained in ordinary run, checkpoint, Human Task history and downstream mappings or AI. The key uses existing credential encryption; this adds no raw-database encryption, automatic deletion/TTL, scanner or deletion guarantee. Local bounds are 64 KiB input, 1 MiB complete response, depth 32, 20,000 nodes, 4096 reads and thirty seconds for the whole invocation, rather than vendor guarantees. Real provider authentication, selected-instance permissions/schema/version/entitlement, durable DB/Redis recovery, native DNS/TLS/sockets, Review tutorials and real AI request interpretation remain untested; local production-owner tests use simulated dependencies.

If the original task, wait or approval is replaced while a request is in flight, the attempt keeps its original uncertain claim and cannot attach failure bookkeeping to the replacement. Ordinary failure cleanup can still record the same original attempt after caller cancellation, timeout or revoked execution access; it grants no new authority and the execution lease still fences persistence.

n8n destructive Public API actions

The selected n8n Public API subset now has nine ordinary actions. Delete a credential (credential.delete, n8n_public_api_credential_delete), Delete an execution (execution.delete, n8n_public_api_execution_delete) and Delete a workflow (workflow.delete, n8n_public_api_workflow_delete) each send one destructive WRITE: DELETE /credentials/<credentialId>, /executions/<executionId> or /workflows/<workflowId>, prefixed by the saved API root. There is no query or body. Credential/workflow IDs are explicit 1–256 ASCII letters, digits, underscore or hyphen; execution IDs are positive safe decimal strings. No collection, wildcard or returned URL becomes a deletion target.

The existing encrypted manual API-key profile and unverified instance edition/version/scopes/entitlement/free-trial prerequisites still apply. All three require the initially unset schema-2 migration, raw-retention and one-attempt controls plus destructiveAcknowledged:true, then a separate original-actor Human Task showing the saved account, origin/root, exact DELETE path and named resource ID. Imported string "true", 1, null and invalid objects remain visible and unchecked until explicitly repaired; opening or saving another field never grants consent. Current workspace and organization authority, policy/account revision, original taskId and waitTokenId, immutable request and lease/claim/CAS checks still apply, including later authenticated OUTPUT.

A genuinely empty HTTP204 or HTTP200 response maps to data:{resource,id,response:"empty"}, with zero examined/returned records and outcomeVerified:false; it observes a response and does not prove deletion. HTTP200 expected metadata maps to response:"metadata" and bounded metadata, with an exactly matching target ID. Credential metadata is only id/name/type; execution data omits runData/workflowData/customData; workflow data omits parameters/settings/pinnedData/connections/credential references. JSON null, whitespace, malformed/unexpected bodies, wrong IDs and other statuses are withheld. There is no deleted:true, automatic readback, paging, polling, retry or uncertain-effect replay. Map node.<id>.json.data.id, .response or available .metadata.name/.status; names and IDs may contain PII retained in ordinary history and downstream mappings, without a new raw-database encryption, TTL/deletion or scanner guarantee.

Real deletion effects, provider authentication, durable DB/Redis, native DNS/TLS and matching-revision Review remain untested. Use only separately authorized disposable resources for live verification; existing credentials, workflows and executions are not test targets. Credential create, workflow create/update/activate/deactivate/getVersion and Tool/Trigger remain unavailable; nine actions do not establish full-node parity.

AWS Transcribe job requests and metadata

The partial AWS Transcribe subset supports four ordinary numeric-version-1 actions: transcribe.transcriptionJob.create, transcribe.transcriptionJob.delete, transcribe.transcriptionJob.get and transcribe.transcriptionJob.getAll. Transcript downloading, simplification, automatic language detection, unbounded pagination and Tool/Trigger forms are unsupported. This is partial service coverage, not full-node or provider parity.

Save an existing awsTranscribeManualSigV4V1 account with profile aws-transcribe-manual-sigv4-v1, partition aws, one of twenty pinned standard regions, declared twelve-digit account ID and manual access keys. Named fields and Advanced JSON use the same encrypted, write-only account. manual-static omits token and expiry; manual-temporary requires an explicitly supplied session token and actual UTC expiry, with more than ninety seconds remaining at execution. Save/update/reopen is local and unverified with zero provider HTTP/DNS. Test and bulk Test are unavailable. No ambient/system/role credentials, STS acquisition, refresh, discovery or custom endpoints are used. The declared account does not prove AWS identity.

Import exact n8n-nodes-base.awsTranscribe with numeric typeVersion:1, preserve original parameters and credential references, and repair the schema-2 input deliberately. Select the exact saved account and set the initially unset migrationAcknowledged:true and rawRetentionAcknowledged:true controls. Imported strings such as "true", numbers and null remain invalid, unchecked and preserved until an explicit click or repair. Unknown and inactive fields remain repair items; embedded credentials are refused before source-ledger persistence. Original get defaults to returnTranscript:true; that intent is unsupported and is never silently converted to metadata.

Create requires an explicit unique transcriptionJobName, authorized same-region s3://bucket/key media URI, mediaFormat, detectLanguage:false, supported languageCode and an explicit options object. The original v1 node has no media-format field, so imports require manual format selection. Supported original settings include channel identification, maximum alternatives/speaker labels (2–10), vocabulary name and a complete vocabulary-filter name/method pair. Channel identification cannot combine with speaker labels. Deliberately set the initially unset processingAcknowledged:true: AWS obtains the authorized media, processes speech, may charge costs and retains job/transcript data under its policies; the app never fetches the media URI. A QUEUED or IN_PROGRESS result remains pending. No polling or completed-transcription claim follows submission.

Delete requires the explicit job name and initially unset destructiveAcknowledged:true, then a separate original-actor Human Task showing the exact AWS request. An actual empty HTTP200 body yields empty operationData:{} with responseReceived:true and outcomeVerified:false. It is response evidence only; job deletion completion and transcript object removal are not verified. There is no fabricated success:true, hidden readback or automatic resend.

Get requires returnTranscript:false explicitly. It returns bounded typed job/status/time/media/transcript-location metadata in operationData. Transcript locations remain inert JSON strings, including on COMPLETED jobs: the app never fetches a provider-returned URI or simplifies a transcript. Get All requires explicit returnAll:false, limit 1–100, filters:{} or supported original status/name filters, and boundedPageAcknowledged:true. It returns one partial page envelope with TranscriptionJobSummaries and any actual top-level NextToken. Copy that token into nextToken only for a separate manually approved next request. A short or empty page does not prove exhaustive inventory; the original broken unbounded paginator is not reproduced.

Only the original run actor can approve the exact request within fifteen minutes. Current workspace and organization authority, selected account, published node/version, run input, resolved request, original task ID, wait token, stable durable decision and execution lease are checked through claim, dispatch, settlement and fresh OUTPUT. Replacement never renews consent. One claim permits at most one physical attempt despite workflow retries; timeout, revocation, disconnect, expired lease or uncertain settlement cannot authorize resend. Same-lineage failure cleanup grants no new authority and remains fenced by the real lease.

Local limits are 16 KiB request, 1 MiB whole response, thirty seconds, depth32/nodes20000 and strict unknown-field refusal. Malformed, oversized, unexpected, numerically mistyped or credential-reflecting responses fail closed. Useful job metadata, names and media/transcript locations enter ordinary workflow/checkpoint/Human history and may reach downstream AI. Accepted raw response bytes use the existing encrypted protected Workspace Files mechanism; this adds no raw-database encryption, automatic TTL, plaintext-scanner or deletion guarantee.

En español: selecciona una cuenta manual existente y la acción exacta. Corrige los campos importados y marca cada confirmación deliberadamente. AWS obtiene el archivo autorizado; la aplicación no descarga archivos ni transcripciones. Los trabajos pendientes siguen pendientes, eliminar solo acredita la respuesta y listar devuelve una página parcial con un token manual. Los metadatos y sus ubicaciones pueden conservarse en el historial y llegar a la IA posterior.

Local tests simulate provider/Prisma facts and use actual public resume, Human Task, checkpoint and output owners. Real AWS authentication/permissions/effects, native DNS/TLS, DB/Redis restart, real AI request interpretation and Review workspace/organization Help walkthroughs remain untested because those external environments and credentials are outside this worker's authority. See the official StartTranscriptionJob, DeleteTranscriptionJob, GetTranscriptionJob and ListTranscriptionJobs contracts.

AWS Certificate Manager outcomes

The actual resume producer captures the original task ID, wait token and stable durable decision. Only that original actor and current workspace AND organization authority can authorize the exact action/ARN/account/material. One durable claim allows one request; replaced task/wait/decision or expired lease refuses send/settlement/OUTPUT and never authorizes retry. Unchanged-lineage abort or revoked authority may perform identity-only failure cleanup while the lease remains valid. HTTP200 empty delete/renew results are response-only evidence with outcomeVerified:false, never completed effects. Get/metadata/list retain useful bounded business fields for downstream mapping and ordinary history; accepted raw bytes use encrypted protected Workspace Files with ciphertext-only scanning. No automatic readback, polling, continuation, TTL or raw DB encryption claim. See bounds and untested real-provider behavior.

DynamoDB typed items

DynamoDB PutItem is full replacement; Delete removes the selected keyed item. Their acknowledgement/old attributes observe a response and keep remotePersistenceVerified:false, never persistence proof. GetItem absence is found:false. Query/Scan reads one page with a limit of evaluated items; an empty filtered page may still have a typed cursor, and COUNT is an object. A used claim or expired original acquired lease cannot be replayed; inspect the result separately before deciding on a new confirmed request. See typed requests, examples and limits.

AWS ELB ordinary actions

ELB runs require a separate original-actor Human Task for one exact AWS Query GET. Writes follow the actual Action: add/remove certificate, create/delete load balancer. Public resume preparation captures immutable taskId, waitTokenId and decision revision; current workspace AND organization/account/input/node/policy/lease are rechecked. One physical CAS permits at most one request; expired or uncertain claims never resend. Empty delete/remove XML is response evidence, never success:true or completed remote effects. Useful exact operationData and protected raw XML remain bound at fresh OUTPUT. Get Many is one partial page with manual Marker/NextMarker only; no retries, polling, discovery or readback. See actions, controls, limits and repair policy. Real AWS effects, native transport, durable DB/Redis and matching Review tutorials remain untested.

AWS Cognito User Pools response evidence

Approve each exact admin request with the original actor's separate Human Task. Its immutable task ID, consumed wait token and stable decision revision remain fenced by current workspace AND organization authority and the actual execution lease. One physical claim CAS permits one attempt. A timeout, disconnect, replacement decision or expired claim never authorizes automatic resend or cascade; partial effects remain unknown. Empty HTTP200 for deletion, membership or attribute update proves only an observed response, with outcomeVerified:false. Lists return one partial page with target-specific NextToken or PaginationToken, never automatic continuation. Ordinary business data can persist in history and downstream AI. Real AWS and Review organization/workspace flows remain untested by simulated local facts. See scope and controls.

AWS IAM identity and membership actions

The ordinary numeric-v1 IAM user/group subset covers twelve actions only. It uses the dedicated awsIamManualSigV4V1 account: profile aws-iam-manual-sigv4-v1, partition aws, signing region us-east-1, and fixed global https://iam.amazonaws.com/ over HTTPS443. Use named fields or Advanced JSON for manual static keys, or a supplied temporary token with its actual UTC expiry. Save and reopen are encrypted, write-only, local and unverified; Test is disabled. No ambient, system, role, metadata, STS, credential acquisition or refresh is used.

Exactly one requested Action is sent by form POST with Version 2010-05-08. Identity, access and membership changes require explicit acknowledgments and a separate original-actor Human confirmation. DeleteUser/DeleteGroup fail on provider dependencies; they never remove memberships, login profiles, MFA, policies or access keys implicitly. Membership add/remove are separate exact user/group operations. CreateUser supports path, tags and permissions boundary; updates support path and rename only. No policy, role, access-key or login-password CRUD is added. HTTP200 is provider response evidence, never verified effect completion.

Lists require explicit returnAll: false, limit 1–1000 and bounded-page consent. GetGroup also pages Users; IsTruncated and opaque exact Marker remain visible even when Users are omitted. Continue only with another separately approved request. No automatic paging, membership scans, discovery, loaders, post-read, retries, returned-URL fetching or redirects. Original helper, returnAll and includeUsers semantics that cannot be preserved remain visible for manual repair; unknown fields and invalid consent types survive export/reopen. Embedded credentials are refused before source-ledger persistence.

Typed user/group identity, ARN, path, creation time, tags, boundary and explicitly selected membership data plus an exact raw reference enter ordinary run/checkpoint/Human history and may reach downstream AI. Account encryption adds no raw database encryption, automatic TTL or scanner guarantee. A bounded XML decoder rejects DTD, external/custom entities, duplicate or wrong envelopes, malformed members, unknown fields/status and credential reflection before retaining raw data. Current workspace and organization permissions, account, input, policy, immutable original task/wait/decision and lease are rechecked through claim, send, response, settlement and fresh OUTPUT. Uncertain or expired claims cannot resend. Local bounds: 32 KiB request, 1 MiB response, 30 seconds. Real AWS, hosted Review and full node/provider parity remain untested.

AWS S3 ordinary bucket subset

The partial ordinary S3 subset covers only s3.bucket.create, s3.bucket.delete, s3.bucket.getAll and s3.bucket.search: four of twelve actions, with exact numeric source V1/V2 imports analyzed separately. Search is ListObjectsV2 object metadata, not a bucket-name search. Object upload/download/copy/delete, folder deletion, multipart, Tool and Trigger remain unsupported.

Save awsS3BucketManualSigV4V1 / aws-s3-manual-sigv4-v1 with partition aws, an explicitly known us-east-1 or eu-west-1 region, declared twelve-digit account ID and manual static keys or supplied temporary token plus actual UTC expiry. Temporary execution needs over ninety seconds remaining. Named fields and Advanced JSON use encrypted, write-only, unverified local Save/update/reopen with zero provider HTTP/DNS. Test, bulk Test, STS, system/role chains, refresh, custom endpoints and discovery are unavailable.

Every request requires schema2 and initially unset migrationAcknowledged, rawRetentionAcknowledged, regionAcknowledged and billingAcknowledged, all literal true, plus action-specific consent. Raw string "true", 1, null and objects remain visible and unchecked until a deliberate click. Then a separate original-actor Human Task approves the exact request. Current workspace and organization access, account, node, input, policy, original task ID/wait token/stable decision and real execution lease are checked through the one durable claim, send, response, settlement and fresh OUTPUT. Expired or uncertain claims never replay.

Create requires name, additionalFields:{} (or a matching known region) and name/global-namespace/security/write acknowledgments. It sends one PUT: empty body for us-east-1, matching XML LocationConstraint elsewhere. Only provider secure defaults are supported; all original ACL/grant/ownership/tag/object-lock intent stays for explicit repair. HTTP200 empty body yields response evidence with effectConfirmed:false; Location remains inert manual metadata. Creating an existing owned us-east-1 bucket can reset ACLs under AWS behavior; inspect the exact name and permissions manually before approval.

Delete requires name, empty-bucket/global-namespace/destructive acknowledgments and sends one DELETE. The bucket must already be empty of objects, versions and delete markers; nothing enumerates or deletes them or changes protection/ownership. Only HTTP204 empty body is accepted as response evidence, never confirmed deletion. A deleted global name may be reused by another account.

ListBuckets (getAll) needs explicit returnAll:false, limit:1..1000, filters:{} and boundedPageAcknowledged:true. This is a local cap, not the AWS maximum10000. Optional filters.bucketRegion must equal the endpoint region; filters.prefix filters bucket names. Output preserves actual ContinuationToken; copy it byte-for-byte into nextToken for a separately approved request. Unpaginated accounts with approved quota above10000 may be rejected; no auto-page or local slice is used.

ListObjectsV2 (search) needs bucketName, explicit returnAll:false, limit:1..1000, additionalFields:{}, bounded-page and Requester Pays acknowledgment. Supported typed options are prefix, delimiter, encodingType:url, fetchOwner, startAfter and requesterPays; the payer is a header. Dotted names use regional HTTPS443 path style. Output keeps bounded Contents, CommonPrefixes, KeyCount, IsTruncated, keys, ETags, sizes, storage classes, dates and actual NextContinuationToken; tokens and keys remain inert values. No content or returned URL is fetched. Empty XML containers and singleton/many entries normalize without fabricated rows.

Original versions keep exact parameters and credential references. V1 ignores the location region during signing; V2 forwards it and handles dotted search names differently. Both original location reads, null/us-east-1/EU assumptions, returnAll/default/limit and unsupported options require visible manual repair. No hidden GetBucketLocation/HeadBucket/readback, redirect, follow-up, polling or retry occurs. Local32KiB request/1MiB response/thirty-second bounds apply; malformed, duplicate, DTD/entity/XXE, wrong-envelope, oversized or credential-reflecting replies fail before accepted artifact retention. Useful metadata and tokens enter ordinary run/Human history and downstream AI; account encryption adds no raw DB encryption, TTL or scanner guarantee.

En español: selecciona una cuenta manual existente y una región conocida, corrige el origen V1/V2 y marca cada confirmación de forma deliberada. Crear y eliminar solo acreditan respuestas; listar devuelve una página parcial y buscar lista metadatos de objetos. Copia el token exacto para otra solicitud aprobada. No se descargan objetos ni se eliminan sus versiones.

Local tests simulate provider/Prisma facts. Real AWS credentials, permissions/effects, native DNS/TLS, DB/Redis restart, AI request interpretation and Review workspace/organization Help walkthroughs remain untested because they are outside this worker's authority. See CreateBucket, DeleteBucket, ListBuckets and ListObjectsV2.

TheHive v1 manual case reads

TheHive and TheHiveProject are two imported wrappers of one Query API service. Only exact ordinary version-1 n8n-nodes-base.theHive and n8n-nodes-base.theHiveProject with explicit case/get are supported. Choose case.getLegacy with theHiveApi and explicit apiVersion: "v1", or case.getProject with theHiveProjectApi. Legacy input is { "id": "~case-id" }; Project input is { "caseId": "~case-id" }. Project also accepts the original manual ID locator. Tool/Trigger variants, missing versions, v0, writes, options, arbitrary queries, list/URL locators, loaders, binary and asynchronous actions require manual repair. Original source controls remain retained and checked.

Save an existing API key with an explicit public HTTPS origin (no subpath, credentials, query, fragment or custom port), exact wrapper profile and an explicit organization policy:

{
  "profile": "theHiveApi",
  "apiVersion": "v1",
  "url": "https://incident.example.org",
  "ApiKey": "SYNTHETIC_EXISTING_API_KEY",
  "organization": { "mode": "named", "name": "responders" },
  "allowUnauthorizedCerts": false
}

For Project, use profile: "theHiveProjectApi" and omit apiVersion. Named fields and Advanced JSON use the same validator; save, update and reopen are local and unverified, with zero provider HTTP. Test and bulk testing are unavailable. Choose { "mode": "default" } explicitly to use the API key owner's default organization, or named scope to send X-Organisation. The application does not discover or verify that organization. A private-only installation is outside this public-origin policy; deployment outbound policy and reachability remain unverified.

Both reads need a separate signed 15-minute Human Task decided by the original run actor. Current workspace and organization membership, account, workflow, input, policy, task, wait, durable decision and execution lease must still match. One physical claim permits one bounded POST to /api/v1/query?name=get-case-…; retries, polling, paging, refresh and returned-link fetching are unavailable even if node retries are enabled. Legacy sends only getCase; Project adds exactly page 0 to 10 with extraData: ["attachmentCount"].

Outputs retain the wrapper's sourceIdentity, case ID, case number, title, unknown business fields and Project attachment count. Zero results return kind: "no-record"; incomplete/malformed/error/mismatched responses are refused. Numeric tokens that cannot pass the explicit precision policy are refused instead of rounded. Only a fully validated bounded response may be retained as an application-encrypted Workspace File; the configured scanner sees ciphertext. Useful business data can persist in workflow history and downstream steps. Fresh OUTPUT admission verifies current authority and the exact signed receipt and raw artifact, with no resend after uncertainty. Installed API version, provider acceptance, key permissions, actual organization visibility, native network behavior and matching-revision Review remain unverified; this is partial support.

Odoo contact reads

One original-actor Human Task shows both exact stage intents and the origin/database/username/query/fields/offset/limit. Each physical stage has a durable CAS claim and current workspace AND organization/account/input/node/policy/task/wait/decision/lease fences. common.login is attempted once; its exact response ID and nonfalse safe UID must validate before one business read. A stalled/ambiguous stage cannot be replayed by fresh gateways. Both stages share30s, with at most two HTTP attempts total. GetAll is explicitly partial, with manual continuation and no fabricated totals/hasMore. Encrypted validated raw stages support fresh OUTPUT authentication; selected contacts still enter ordinary history/AI.

Deployment/version, Custom plan, model, ACL and public reachability are unverified. Local provider/Prisma facts are simulated; real provider/native/DB/Review organization and workspace behavior is untested. See the complete bounded protocol and limitations.

Splunk exact metadata request

A Splunk exact-request approval pause sends zero HTTP. Review the selected encrypted account, explicit HTTPS443/8089 origin, existing SID and initially unchecked migration, retention and one-attempt acknowledgments. Only the original actor with current organization AND workspace execution access may confirm. Original task ID, wait token and stable decision revision, account/node/input/policy revisions and the live lease are checked before claim, send, response settlement and fresh OUTPUT. A generic completed-effect cache cannot bypass this owner.

One successful durable claim allows at most one GET, including when workflow retry settings request three attempts. Authentication/permission/rate/transport/error-envelope/timeout/invalid-response failures withhold success and never authorize resend, polling, redirect or hidden readback. Cancellation, revocation or lease expiry after claim leaves no new send authority. Failure cleanup is fenced to the original task/wait/decision/lease identity. A separate intentional request requires new preparation and confirmation.

A matching metadata response can feed later mapping; it does not establish completed-job/result completeness. Current provider/deployment acceptance, native DNS/TLS, durable DB/Redis restart, real AI request interpretation and matching-revision Review tutorials remain untested. Local provider and Prisma facts are simulated; Review and live provider evidence must be obtained separately.

YouTube exact snippet approval

Preparing the exact video.get request sends zero provider calls. The original actor reviews one selected saved account, video ID, fixed Google origin, literal snippet part and public-item retention in the Human Task. Confirmation requires current direct organization and workspace membership, current account material, live setting and lease; the consumed original task/wait/decision is checked before HTTP and persistence. A single physical claim prevents replay even if its success/failure effect entry is later removed or changed. Two fresh resumes cannot use the same consumed decision to resend. An ambiguous transport outcome remains explicitly unverified: inspect YouTube separately before intentionally creating a new request. No automatic retry, paging, token refresh or generic completed-effect bypass is available. Empty items:[] succeeds; HTTP401/403/quota errors fail. Real provider, Review and persistence-restart behavior have not been tested.

X (Twitter v2): one username lookup

The useful native unit is exact ordinary numeric typeVersion: 2 user.searchUser, using one explicit username of 1–15 ASCII letters, digits or underscores. It sends one GET https://api.x.com/2/users/by/username/{username} with no query or body. The current documented hostname differs from original api.twitter.com; support for that old alias remains unverified, and redirects are refused. Original default tweet/resource conversion, v1/OAuth1, me/ID lookup, writes, extra fields, expansions, multiuser, paging and retries are visibly unsupported. Import retains original source ledgers and requires explicit repair and account reselection.

In Connections, choose X (Twitter v2) and enter your existing bearer in the named accessToken field, or Advanced JSON {"profile":"xUserV2ManualBearerV1","accessToken":"YOUR_EXISTING_TOKEN"}. Save/update/close/reopen use existing encrypted storage, remain unverified and send zero HTTP/DNS. Test is unsupported and bulk Test skips this account. OAuth2 PKCE acquisition/refresh and original OAuth or broad-scope aliases are not provided. Current X endpoint authorization and credits/pay-per-use require a suitable account; actual grants, entitlement, credits and visibility remain unverified without a real provider test.

In Builder, select user.searchUser, the exact saved workspace account and the username, and explicitly check migrationAcknowledged, outputRetentionAcknowledged and onePhysicalAttemptAcknowledged with schema version2. Current workspace live preference AND the operator WORKFLOW_LIVE_TWITTER gate are required. The original actor needs current organization AND direct workspace execution membership and confirms the exact material in a separate Human Task. Current account bytes, identity, original wait/decision, workflow/version/input, consumed resume segment and nonempty owned lease are checked before the physical claim, HTTP and output persistence. Rotation, deletion, retyping, deauthorization, membership/live changes, later resume/retry/recovery, removed/tampered claims and expired leases refuse further dispatch; uncertain outcomes never automatically replay.

The bounded original data user object is returned as data and one original-style item in sourceItemsJson. String snowflake data.id keeps precision. data.name, data.username and bounded unknown nested business fields are available to ordinary output, run history and downstream mappings, and may contain personal information. The raw response envelope and unknown outer fields are discarded; no plaintext raw artifact or new encryption purpose is introduced. Returned URLs remain inert. Explicit credential VALUES (including encoded forms) are refused on reflection; unrelated business field names are retained. Not-found, rate-limit, credits, auth, duplicate keys, malformed/unsafe values and partial errors fail instead of returning an empty user.

Local bounds are one physical attempt, total30s, response1MiB, depth32 and20k nodes. These are local bounds, not vendor quotas or a deletion/scanning guarantee. Current provider service, Review organization walkthrough, native DNS/TLS and durable DB/Redis restart are untested; local HTTP/Prisma/DOM simulations do not establish them.

PayPal: one payout item read

The native partial operation is ordinary n8n-nodes-base.payPal, numeric typeVersion: 1, payoutItem.get. It sends exactly one GET /v1/payments/payouts-item/{payoutItemId} on the saved explicit live (https://api-m.paypal.com:443) or sandbox (https://api-m.sandbox.paypal.com:443) environment. Enter one explicit string ID; numeric coercion, paths, query controls and returned links are refused.

Save a dedicated PayPal account through Named fields or Advanced JSON:

{
  "profile": "paypalPayoutItemManualBearerV1",
  "environment": "sandbox",
  "accessToken": "YOUR_CURRENT_MANUALLY_SUPPLIED_TOKEN"
}

Both editors use the same central validator. Save, update, close and reopen are local encrypted, write-only and unverified, with zero provider HTTP or DNS. Test is unavailable and bulk Test skips this profile. The original payPalApi client ID/secret credential and its hidden authorization POST are separate and unsupported. No OAuth acquisition or refresh occurs; replace an expired manual token yourself. sanbox, omitted environments and arbitrary fallbacks are refused. PayPal Payouts enablement, token expiry, merchant transaction visibility, current permissions and quota remain unknown without real account verification. The application's organization is distinct from the PayPal merchant identity.

Use parameterSchemaVersion: 2, an explicit payoutItemId, and independently check migrationAcknowledged, outputRetentionAcknowledged and onePhysicalAttemptAcknowledged. These acknowledgments start unset. Imported unsupported resources, versions, extra parameters and original credential references remain visible in the source ledger for manual repair and explicit account reselection. Only the original actor with current direct workspace and organization membership can approve the exact account, environment, route and retention in a separate Human Task. Current saved account material, live environment gate WORKFLOW_LIVE_PAYPAL, workspace preference, original task/wait/decision, resume segment and lease are rechecked at claim, dispatch, settlement and output admission. A removed or changed effect record, expired lease, deletion, rotation, retyping, deauthorization or lost membership cannot authorize a resend or account fallback.

The useful single payout-item object appears in result.data and the one-element result.items array. It retains string identifiers, nullable values and nested unknown business fields, including recipient and financial data, in ordinary execution history and downstream mappings. Review those fields before sending them to another action or AI step. The bounded raw HTTP text and transport envelope are discarded after parsing; no encrypted raw-response archive, new TTL, deletion or scanner guarantee is added. Exact credential values echoed in any key or value are refused; business fields are not removed because of their names. Provider errors and not-found responses are failures, while a payout item's documented business status such as FAILED is preserved as business data.

One consumed decision permits one physical request with a total real 30-second deadline, 1 MiB response, depth 32, 20,000-node and finite-read limits. Duplicate JSON keys, invalid UTF-8/media/status, numeric precision loss, overflow, redirects and ambiguous outcomes fail closed with no automatic retry. Payout create/get/list, payout-item cancel, other resources, triggers, dynamic loaders, pagination, returned-link fetching and token acquisition/refresh remain unsupported. This one selected read is not complete PayPal parity. Tests use simulated HTTP/Prisma/DOM facts; real PayPal, native DNS/TLS, a durable database restart, real AI interpretation and the matching authenticated Review workspace/organization tutorial walkthrough remain untested.

Primary endpoint contract: PayPal payout item details.

SMTP import repair

An SMTP import requires repair error stops an imported emailSend node before the SMTP hook or completed-effect callbacks. Review the source version, email/send operation, selected format and options, then select a configured saved SMTP account. Version 2.1's default n8n attribution must be deliberately reviewed and disabled for this subset. Attachments, Reply To and unsupported TLS/host-name settings cannot be silently dropped. Follow the repair steps, save and reopen the workflow, and review validation again. Clearing an issue notice alone does not fix the source intent. Simulation prepares a mail request without sending it; SMTP acceptance does not prove recipient delivery.

Microsoft Dynamics: one Dataverse account read

The native Dynamics profile supports account.get, account.getAll, account.create, account.update and account.delete on the saved public commercial HTTPS {environment}.crm.dynamics.com origin at port443, using /api/data/v9.2/accounts. Other regions, sovereign/on-premises endpoints, other tables, lookups, loaders and Tool/Trigger variants remain unsupported.

Save the dedicated dynamicsAccountManualAccessTokenV1 profile in Named fields or Advanced JSON with accessToken, exact environmentOrigin, matching declared audience and Unix-millisecond expiresAtMs. Save/update/reopen are encrypted, write-only, local and unverified with zero provider HTTP/DNS. Test and OAuth acquisition/refresh are unavailable; historical microsoftDynamicsOAuth2Api credentials are never converted. Declarations do not verify real token grants, tenant consent, licensing or security roles. At least30 seconds of declared lifetime must remain at execution.

Create/update accept the supported text, Int32, four-decimal Money, stage GUID and up to two address rows. Other columns, deep inserts and lookup bindings require another integration. Dataverse plug-ins, flows, business rules and auditing may run for writes. HTTP acceptance does not verify their completion; an uncertain write may already have occurred and never retries automatically.

Set parameterSchemaVersion:1, then independently select literal migrationAcknowledged, rawRetentionAcknowledged and onePhysicalAttemptAcknowledged. Create/update additionally require consequentialEffectAcknowledged; delete requires destructiveAcknowledged. All start unset. Expressions cannot grant consent. The original actor with current direct workspace AND organization membership must approve the exact account, method, body, retention and effects in a separate Human Task. Current account/secret, node/input, live policy, original decision, owned lease/checkpoint/native resume and one physical CAS claim bind dispatch and fresh OUTPUT. Used, expired or uncertain claims never resend.

Raw JSON, numeric lexemes, bounded records and unknown business fields enter normal history and downstream mappings. Links remain inert. Local caps remain30 seconds, 1MiB response, depth32,20,000 nodes,4,096 reads and6MiB output; malformed UTF-8/JSON, duplicate keys, invalid status/media or identity mismatch fail closed. Documented application/json; odata.metadata=minimal is accepted. Real Dataverse rights, provider effects and durable restart behavior remain unverified; local provider/socket/database tests are simulated.

Automatic import accepts only exact ordinary numeric version1 get/getAll/create/delete with explicit supported controls; Return All is refused. Original update requires manual migration because of its upsert semantics. Source ledgers retain parameters, versions and credential references without selecting an account or granting consent; export/reopen preserves invalid drafts until deliberate repair.

Primary contracts: retrieve a row, create a row, update and delete.

S3-compatible first-page recovery

A generic-s3 first-page run requires the same original actor, current direct workspace and organization access, live policy, exact saved account revision, raw literal acknowledgments, Human task/wait/decision and owned execution lease through claim, response and fresh output. Editing the input or replacing the account requires new approval. An uncertain, consumed or tampered claim cannot resend under the same decision; fresh output resumes revalidate the retained receipt and current authority without another provider request. The action performs no continuation, so partialPage:true is expected even when the response reports isTruncated:false. Do not interpret an unverified local Save or simulated test as endpoint access verification. See the first-page limits.

Redis native GET and uncertain sessions

Redis string GET requires the exact current external account, the original actor's signed Human decision, organization AND workspace authority, a current owned execution lease and one physical CAS claim. AUTH and SELECT precede one GET. A missing key returns null with missing:true; empty string stays empty and WRONGTYPE fails. Saved text is not parsed as JSON or coerced into a number.

DNS rebinding/private answers, TLS identity failures, changed account/member/input/node/policy, malformed UTF-8/RESP, byte/read/deadline bounds and unconfirmed close withhold success. Rejected or uncertain claims never resend, including through a fresh gateway or configured workflow retry. Fresh OUTPUT rechecks the trusted resume revision, lease, original task/wait, stable decision and signed settled receipt. Inspect an uncertain provider session separately before deliberately preparing a new request. Local simulated facts and real timer checks do not certify actual Redis/native networking, durable database restart or matching Review organization/Help behavior.

Xero: one existing-tenant contact read

The native ordinary numeric version1 subset is contact.get: one GET https://api.xero.com/api.xro/2.0/Contacts/{contactId} with an explicit UUID and Xero-tenant-id. Save the exact xeroContactManualTokenV1 JSON profile with tokenKind: "oauth2-access-token", manually supplied accessToken, existing tenantId and granted contactsScope (accounting.contacts.read or accounting.contacts). The external Xero tenant is distinct from the current application organization. Named fields and Advanced JSON Save/update/reopen are encrypted, write-only, local, unverified and send zero HTTP/DNS; Test and bulk Test skip. No OAuth refresh or tenant discovery.

All seven explicit boolean migration, output-retention, one-attempt, selected-account, tenant-authorization, approved-usecase and associated-user data-passthrough acknowledgments start unchecked and must be literal true. These user attestations never prove Xero approval or activate Live. The original actor separately decides the exact Human task; current organization AND workspace membership, account/material, node/input/policy, consumed decision, owned lease and one CAS physical claim are revalidated through persistence and fresh OUTPUT. Current provider approval, token/tenant entitlement and associated-user consent remain unverified; resolve those before actual provider activation/testing. Current Xero terms restrict approved use cases, third-party passthrough and model training/adaptation; they do not establish a blanket inference ban.

One exact contact in data and sourceItemsJson preserves bounded original business JSON, including normal prototype-shaped keys and possible personal, bank or tax information, in ordinary output/history/downstream. The raw envelope is discarded; returned URLs stay inert. Local30s/1MiB/fatalUTF8/structural bounds, zero redirects/retries and consumed receipts prevent automatic replay of uncertain attempts. Import/export/reopen retain unsupported raw intent, raw versions and credential IDs; no automatic consent or OAuth-credential alias. Invoice, list, writes, Tool/Trigger and fullnode parity remain unsupported. Real provider, DNS/TLS, Review, durable DB/restart and real human authentication remain untested.

Consent must be saved as seven literal true booleans; acknowledgment expressions are unavailable and cannot acquire consent by resolving to true. A timely settled contact can pass through a later Wait under a new trusted resume revision and current owned lease, with its original signed task/wait/decision/claim/result conserved and current authority checked again; OUTPUT never sends again. The original send approval expires after15minutes; a timely signed settled result may outlive that send window, while retries, recovery or changed checkpoint attempts refuse.

QuickBooks bill-read recovery

A QuickBooks bill.get uses the exact manual account's company realm/environment and one original-actor Human decision with current organization AND workspace, account revision, owned lease, checkpoint and physical CAS authority. Financial-data persistence consent must remain literal true before rendering and on restored WAIT. Changed authority/account, expired declared token metadata, cancellation, deadline, redirects, Fault or malformed/unsafe JSON stop success. No retry, refresh or automatic resend follows an uncertain used claim; fresh OUTPUT revalidates the settled result and current authority without another request.

The open Bill must have the requested string Id. Parsed financial/contact data, unknown fields and exact rawResponseJson enter ordinary output/history/downstream persistence; raw decimal spelling is retained and parsed decimals are not exact arithmetic. Version75 is a floor/default, not a complete frozen schema. Inspect the failure, replace expired metadata/token with complete same-ID Update account if appropriate, and prepare a new deliberate approval; a local Save/Test skip never proves Intuit access. See QuickBooks account, local decimal-ID subset and limits. Real provider/native network, durable database/restart and Review organization/Help behavior remain untested.

AWS Rekognition DetectLabels (preview)

DetectLabels pauses for approval before its single physical attempt. The original actor must approve the exact request with the selected saved account and all six acknowledgments. Current organization/workspace authority and live settings are checked again on resume. A successful response retains complete labels, model metadata and bounded raw JSON; missing Labels or an AWS error envelope is refused. Empty Labels is a valid empty result. A lost or uncertain paid result is terminal unknown: inspect execution history and do not automatically rerun it.

Execution requires both the deployment setting WORKFLOW_LIVE_NATIVE_REKOGNITION=true and the workspace live preference for aws-rekognition. Human approval belongs to the original actor and binds the saved account, exact source, input and workflow version. Changes require a new approval. An uncertain paid outcome must not be replayed.

Real AWS requests and authenticated organization/workspace Review walkthroughs remain untested. Local simulated responses do not verify AWS permissions, image access or provider retention settings. See DetectLabels fields, acknowledgments and limits.

Español: DetectLabels en vista previa

DetectLabels se pausa para aprobación antes de su único intento físico. El actor original debe aprobar la solicitud exacta con la cuenta guardada elegida y las seis confirmaciones. Al reanudar se comprueban de nuevo la autoridad vigente de organización y workspace y la configuración de ejecución real. Una respuesta válida conserva etiquetas completas, metadatos del modelo y JSON bruto acotado; se rechaza la ausencia de Labels o un error AWS. Labels vacío es un resultado vacío válido. Un resultado facturable perdido o incierto queda como desconocido terminal: revisa el historial y no lo repitas automáticamente.

La ejecución exige tanto WORKFLOW_LIVE_NATIVE_REKOGNITION=true en el despliegue como la preferencia de ejecución real de aws-rekognition en el workspace. La aprobación humana corresponde al actor original y vincula la cuenta guardada, el origen exacto, la entrada y la versión del flujo. Los cambios exigen una nueva aprobación. Un resultado facturable incierto no debe repetirse.

Siguen sin probarse las solicitudes reales a AWS y los recorridos autenticados de organización y workspace en Review. Las respuestas locales simuladas no verifican permisos de AWS, acceso a la imagen ni la política de retención del proveedor. Consulta los campos, confirmaciones y límites de DetectLabels.

AWS Textract AnalyzeExpense (preview)

Before running, verify the ready workspace image, native account, five literal acknowledgments and both live gates. Human shows the exact full-image request for the original actor's separate approval. On resume, organization AND workspace access, account revision, source, workflow version and file content are rechecked. A changed or unavailable image requires preparing a new approval.

One durable attempt claim precedes the provider request. Cancellation, network failure or lost response can leave a paid outcome uncertain. Such an attempt is terminal and must not automatically repeat; inspect history before preparing a separate explicit request. A fresh successful output requires a settled authentic receipt and complete bounded response. Rejected or uncertain attempts must not manufacture successful output.

The full base64 image and raw expense response can persist in ordinary approval and execution history and flow to downstream AI. An acknowledgment does not verify AWS retention settings or OCR truth. Local tests with simulated provider responses and controlled TLS peers do not establish real AWS permissions or authenticated Review behavior.

Execution requires both the deployment setting WORKFLOW_LIVE_NATIVE_TEXTRACT=true and the workspace live preference aws-textract. Real AWS requests and authenticated organization/workspace Review walkthroughs remain untested.

Español: AnalyzeExpense en vista previa

Antes de ejecutar, comprueba la imagen lista del workspace, la cuenta nativa, las cinco confirmaciones literales y ambas autorizaciones de ejecución real. Human muestra la solicitud con imagen completa para la aprobación independiente del actor original. Al reanudar se revisan acceso a organización Y workspace, revisión de cuenta, origen, versión del flujo y contenido del archivo. Una imagen cambiada o no disponible exige preparar otra aprobación.

Se registra un único intento durable antes de enviar la solicitud. Cancelar, perder la conexión o perder la respuesta puede dejar un resultado facturable incierto. Es terminal y no se repite automáticamente: revisa el historial antes de preparar una solicitud explícita independiente. La salida exitosa nueva exige un recibo auténtico asentado y una respuesta completa limitada. Un intento rechazado o incierto no debe fabricar éxito.

La imagen base64 completa y los gastos sin procesar pueden persistir en historial ordinario y llegar a IA posterior. Confirmar no verifica la retención AWS ni la exactitud del OCR. Las pruebas locales con respuestas simuladas y servidores TLS controlados no establecen permisos AWS ni el comportamiento autenticado en Review.

Se exige tanto WORKFLOW_LIVE_NATIVE_TEXTRACT=true en el despliegue como la preferencia real aws-textract del workspace. Siguen sin probarse las solicitudes reales AWS y los recorridos autenticados de organización y workspace en Review.

Additional Firestore and GA4 operations

Additional native Firestore actions

The same selected manual datastore token also supports the following explicitly configured native actions in the (default) database. Each uses the existing three literal migration/retention/one-attempt acknowledgments plus a separate original-actor exact-request Human Task. Current organization AND workspace membership, account revision, input, policy, owned lease, one physical CAS and fresh OUTPUT checks still apply.

No item/column inference, derived document IDs or simplification is added. Typed values preserve int64 strings, bytes, references and timestamps; unknown business metadata remains inert. Writes/deletes are billed and may take effect even if their response is lost; they never retry automatically. Repeating a service-assigned create manually can create another document. Request bodies are limited to8KiB; existing64KiB response, depth24,4,096-node/read,30-second total and18-second transport bounds remain. Returned tokens and URLs are never followed. IAM, Rules, quota and real effects remain unverified.

The six additional actions require manual migration: pinned n8n output item shapes and item-derived write fields/IDs differ. Import keeps original intent and a specific repair reason instead of silently changing semantics; the existing narrow document.getAll import remains available. Select the account and acknowledgments deliberately after repair.

Primary contracts: Firestore REST documents, structured queries.

GA4 bounded report.run

report.run extends the same manual-token account with up to10 metrics and9 dimensions, listed or explicit API names, custom expression/invisible metrics, one AND/OR group of supported dimension and metric filters, ordering, currency, aggregates, empty-row and quota flags. Use returnAll:false and explicit limit1–1000; the requested rows×columns must also fit the10,000-node structural budget. One8KiB POST body is bound to the Human approval; no offset or subsequent page is requested. Data API token/quota consumption and metric/filter compatibility remain unverified.

Custom dates accept YYYY-MM-DD or offset-free local date-time and send the date part. Native today/yesterday/last7days/last30days use Google's property time zone, which can differ from n8n's host-clock dates. simple:true adds string-valued simpleItems inside one retained output envelope, rather than emitting n8n's separate row items. Raw report and original JSON always remain in normal history/downstream values, including unknown inert business fields. Column identities, row counts and string metric values are validated; rowCount never proves completeness. The existing256KiB/depth16/10,000-node/4,096-read/30-second limits, no-retry policy and current organization/workspace authority checks remain.

Automatic import of the broader numeric version2 ordinary GA4 source requires explicit custom dates and simple:false. Relative presets and simple row items retain a manual-migration blocker because those semantics differ. Source credentials, cached locator URLs and metadata never grant account authority or fetch another URL. Reselect the exact saved token, deliberately check all three initially unset literal acknowledgments, and complete the separate original-actor Human Task. The narrow report.get contract remains available. Universal Analytics, Tool/Trigger, OAuth acquisition/refresh and full-node parity remain unsupported. Real Google access and durable restart behavior remain unverified; local execution tests use simulated provider/database facts.

Primary contract: Data API runReport.

Google language compatibility results and failures

The two literal language import profiles require exactly one incoming item before sending any request. Select the current manual bearer account, deliberately acknowledge disclosure, possible billing and full-response retention, and confirm independently. Translate retains its complete first translation object with input pairing; Natural Language retains its complete response, numeric metrics/offsets and sentence text. Missing optional fields remain absent. No automatic extra item, page, response translation or retry is added.

Inspect a failed request before deliberately repeating it: Google may already have processed and billed it. Malformed, oversized, unsafe-numeric or credential-shaped responses refuse as a whole. Normal secret protection must preserve the full result unchanged, or execution refuses it. Full text and unknown fields may enter ordinary history and downstream AI. Tests cover simulated provider responses only; real Google authority, billing and authenticated workspace/organization Review flows remain unverified.