Data handling and retention

FastHook stores configuration and execution metadata in databases and keeps request payloads and Workflow Step outputs in object storage. Access is scoped by team, but payloads can contain customer or provider data. Minimize what enters a Workflow, avoid credentials in event data, and choose sanitized evidence for incident sharing.

Data created by an automation

| Data | Why FastHook uses it | Operator consideration | | --- | --- | --- | | Source request metadata and payload | Route, inspect, retry, replay, and troubleshoot inbound events | Payloads can contain personal, confidential, or regulated fields. | | Workflow graph and immutable versions | Execute the graph and interpret historical runs | Names, descriptions, mappings, and inline values are configuration, not a secret vault. | | Workflow runs and Step records | Display Audit status, errors, timing, inputs, and outputs | Step output objects can contain provider response data. | | Connected-account metadata and credentials | Subscribe to Triggers, load options, and execute Actions | Usable provider credential material is stored in encrypted envelopes. | | Request fixtures | Preserve selected test payloads for reuse | A fixture is intentionally durable and should be deleted when no longer needed. | | Sanitized request shares | Give another person a bounded incident snapshot | The snapshot is public to anyone holding its unexpired bearer URL. |

Do not send more fields than the automation requires. Apply minimization before FastHook where possible; a Transformation changes later Workflow data but does not erase the original inbound request already captured for routing and Audit.

Workflow Audit previews

Audit metadata is available without loading payload content. The run-detail API loads payload previews only when include_data=true.

For each requested preview, FastHook currently applies these safety limits:

• objects larger than 64 KiB report availability and size but do not return a preview;
• strings are truncated after 8,000 characters;
• arrays and objects are limited to 100 items or fields;
• nested values stop after 10 levels; and
• keys matching authorization, cookies, credentials, passwords, secrets, signatures, tokens, API keys, private keys, or client secrets are replaced with [redacted].

Redaction is key-name based. It cannot reliably identify a secret copied under an innocuous name such as note or embedded inside free text. Keep credentials out of Trigger payloads, Action outputs, mappings, names, and descriptions even when Audit redaction is enabled.

An Audit preview can return expired_or_missing when its object is no longer available. Design incident procedures to record identifiers and provider-side evidence rather than depending indefinitely on full payload previews.

Sanitized request shares

Creating a share stores a sanitized snapshot rather than granting dashboard access to the original request. By default, FastHook:

• includes the body unless include_body is false;
• redacts common auth, cookie, secret, signature, token, and API-key fields;
• accepts up to 100 additional custom redaction keys;
• truncates individual strings after 10 KiB and the complete shared body after 128 KiB;
• limits nested depth, array items, and object fields; and
• expires access after seven days by default.

The TTL can be set from 60 seconds to 30 days. A requested later expiration is capped at 30 days. Expiration prevents public retrieval; it should not be interpreted as proof that the underlying share row or original request data was immediately physically deleted.

Before sharing, omit the body when it is not required, add business-specific redaction keys, open the resulting snapshot yourself, and send the URL only through an approved channel. Anyone holding an unexpired share URL can read the snapshot.

Current cleanup defaults

The cleanup worker’s current backend defaults are operational settings, not contractual or legal retention guarantees. A deployment can override the cutoffs within bounded ranges.

| Record class | Default cleanup cutoff | Cleanup condition | | --- | --- | --- | | Request database rows | 30 days after created_at | Rows at or before the cutoff are removed in batches. | | Event-data database rows | 37 days after stored_at | Payload index/metadata rows at or before the cutoff are removed in batches. | | Completed batch operations | 30 days | Only COMPLETED, FAILED, or CANCELLED operations are eligible. | | Workflow runs | 30 days after finished_at | Only terminal succeeded or failed runs are eligible; their Step rows cascade on deletion. | | Action execution idempotency state | 30 days after updated_at | Only terminal succeeded or failed state is eligible. | | Provider webhook-event and Trigger-run runtime state | 30 days | Only terminal runtime states are eligible. |

Request, event-data, and batch-operation cutoffs can be configured from one hour through 365 days. Workflow-run, Action-state, and provider-runtime cutoffs can be configured from 24 hours through 365 days.

These SQL cleanup cutoffs describe database records. Payload and Step-output objects live in object storage and can have a separate lifecycle. The Workflow-run cleanup query does not itself prove deletion of every referenced object. Confirm the deployed object-storage lifecycle and any backup policy before using these defaults in a compliance statement.

Queued or running Workflow runs are not removed by the terminal-run cleanup. Expired request shares are rejected on retrieval, but the current general cleanup worker does not define share-row deletion. Saved fixtures have explicit delete behavior and should be managed separately from ordinary request retention.

Deletion and account lifecycle

Deleting a Workflow removes its graph-owned records through database relationships and is not the recommended way to stop traffic during an incident. Pause first, preserve identifiers, and understand queued or running work.

Account deletion removes the user’s sessions and data in projects where that user is the only member. Shared projects remain, and the last owner of a shared project must transfer ownership first. Treat account deletion as irreversible and review connected accounts, provider ownership, project keys, and retained fixtures before proceeding.

Data-governance checklist

1. Classify fields that can arrive from each Source and leave through each Action.
2. Separate production and test teams, credentials, payloads, and fixtures.
3. Exclude secrets and unnecessary personal data before ingestion when possible.
4. Set a deployed retention policy for databases, object storage, logs, backups, and sanitized shares.
5. Limit who has team membership, because current protected APIs use membership as their ordinary authorization boundary.
6. Test Audit redaction with realistic payload keys and add custom share redactions for business-specific fields.
7. Document how operators preserve minimal evidence and delete temporary fixtures after an incident.
8. Revisit the policy when adding a provider, changing a Source payload, or mapping a new Action output.

Continue with Security and governance, Secrets and credential rotation, and Workflow production readiness.