Guide: Security and Data Protection

Overview

Syllecta receives webhook traffic and retryable API operation data, so the main security question is data exposure: what is stored, what is visible in the console, how long it is kept, and who can access it.

The product direction is metadata-first. Syllecta should use operational metadata for routine reliability work and treat payload content as debug/replay data with explicit limits.

Security Review Summary

Current shipped controls:

• provider signature verification for supported integrations
• tenant-scoped console/API access
• production callback URL validation for public HTTPS destinations
• private, loopback, link-local, and reserved IP blocking before callback delivery
• redacted dashboard payload views for routine triage
• tenant-level payload storage policy: metadata-only, redacted payload, or raw debug window
• payload search limited to stored redacted payload views and disabled for metadata-only tenants
• audit events for payload detail views, payload search attempts, replay actions, and replay blocks
• replay blocked when raw payload is not stored or the raw debug window expired
• /v1/record body-size and TTL caps so idempotency records stay bounded
• operational retention cleanup for webhook/debug data
• protected financial, audit, and tenant-core records outside generic cleanup
• API keys as one-time reveal/hash-backed records and webhook secrets masked/encrypted for new writes
• webhook ingress body caps, content-type validation, malformed JSON rejection, rate limits, and structured security events
• app-level traffic protection: scanner-path fast rejection, body/timeouts, security headers, private surface no-index headers, manual replay throttles, and dashboard query bounds

Roadmap controls that should not be treated as shipped yet:

• broader audit coverage for support access and credential changes
• dedicated/static outbound IP options for allowlisting-sensitive customers
• managed edge/WAF traffic protection for public web, Backoffice API, and Cloud API surfaces
• formal compliance package, DPA review, and customer-specific security questionnaires

Metadata First

For most recovery workflows, Syllecta needs operational metadata:

• provider and tenant
• provider event id
• event type
• received time and processed time
• delivery status
• callback endpoint and response status
• retry/replay state
• failure reason and correlation id

This is the data operators usually need to answer: did the event arrive, where did it go, did it fail, and what should happen next?

Payload Handling

Webhook payloads can contain customer data. Syllecta supports tenant-level storage modes so teams can choose how much payload data is stored for observability and replay.

Current behavior:

• Webhook event metadata is stored for observability.
• metadata_only stores event metadata only. Payload body search and raw replay are unavailable.
• redacted_payload stores a redacted payload/header view for triage. Raw replay is unavailable.
• raw_debug_window stores raw payload and headers only for the configured replay/debug window.
• Dashboard event detail returns a redacted/safe payload view.
• Payload search is restricted, requires a tenant and date range, and searches the redacted payload view only.
• Payload detail views and payload searches are audit logged without storing the search text.
• Internal replay is explicitly blocked when raw payload is not stored or the raw debug window expired, and blocked/queued retry actions are audit logged.
• The console shows the active payload policy in Webhook Settings and admin tenant settings.

Idempotency records are separate from webhook payload storage. PUT /v1/record stores the response body that should be returned on future cache hits, so it should contain only the operational response data needed for replaying the client response. Syllecta caps record body size and maximum TTL to keep this surface from becoming long-lived arbitrary data storage.

Redaction

Dashboard-facing payload views redact sensitive-looking data by key or value pattern.

Examples of redacted headers:

• authorization
• cookie / set-cookie
• signature headers
• token, secret, api-key-like headers

Examples of redacted payload fields:

• token, secret, api key, password
• email, phone, mobile, address, postal/zip
• card, PAN, CVC, CVV, expiry fields
• IBAN, routing number, account number

Redaction is a safety layer, not a reason to send unnecessary sensitive data. Provider-side minimization should be used when available.

What Not To Send

Do not send these fields to Syllecta unless they are explicitly required for your workflow:

• card numbers or CVC values
• passwords
• access tokens or refresh tokens
• session cookies
• long-lived secrets
• full customer profiles
• unnecessary addresses, phone numbers, or documents

For payment providers, use provider-generated ids and event metadata instead of raw payment credentials or customer secrets.

Retention

Raw webhook payloads should be temporary operational data. The current retention model is:

• raw webhook payloads and headers: short debug window, default 30 days
• synthetic/demo events: shorter operational window, default 90 days
• webhook metadata: longer operational evidence window, default 180 days
• simulations: product evidence window, default 180 days
• job history: routine rows default 90 days; incident rows default 395 days
• billing reconcile history: healthy rows default 90 days; mismatch rows default 395 days
• financial ledger and audit evidence: protected from generic cleanup

Generic retention jobs do not delete billing events, invoices, invoice line items, billing adjustments, payment provider references, audit logs, tenants, users, API keys, webhook secrets, settings, or plans. Those require separate legal/accounting or offboarding decisions.

See the dedicated matrix: Data retention.

Access Boundaries

Tenant users should only see their own tenant data. Admin/support access exists for operational recovery, billing support, and security response.

Required access rules:

• raw payload access should be exceptional
• replay should be audit logged
• support actions should be audit logged
• tenant-scoped users should receive redacted payload views by default
• internal endpoints must stay protected by service-to-service authentication

Secrets and Credential Rotation

API keys and webhook secrets are tenant security credentials. Treat them as one-time operational secrets, not as support-ticket content.

Recommended API key rotation:

1. Create a replacement key.
2. Deploy it to the application or integration that calls Syllecta.
3. Verify new traffic is accepted.
4. Revoke the old key.

Recommended webhook secret rotation:

1. Create or enter a replacement provider secret.
2. Update the provider webhook configuration.
3. Send a provider test event.
4. Confirm verification succeeds in Syllecta.
5. Deactivate the previous secret after the overlap window is no longer needed.

Credential handling is intentionally restrictive: API key values are shown once, then stored as hash-backed records; webhook provider secrets are masked in tenant/admin APIs, encrypted at rest for new writes, rejected when obviously weak, and exposed only to the internal signature verification path. Audit logs record key creation/revocation and webhook secret create/rotate/deactivate actions. Dual-secret overlap remains planned for smoother provider-side rotations.

Shared Responsibility

Syllecta is responsible for:

• verifying supported provider signatures
• enforcing tenant scoping in console/API access
• validating production callback URLs before storage
• blocking callback delivery to private, loopback, link-local, and reserved IP ranges
• redacting dashboard payload views
• retaining operational data only as needed
• providing controls for payload policy, retention, audit, and replay

Customers are responsible for:

• choosing what data their providers send
• avoiding unnecessary sensitive fields in webhook payloads
• rotating provider and API secrets
• configuring callback endpoints safely
• reviewing retention and payload policy before sending production traffic

Callback Egress

Production callback URLs must be public HTTPS endpoints. Syllecta rejects callback URLs that target localhost, private networks, link-local addresses, local-only hostnames, or reserved IP ranges.

Before delivery, Syllecta resolves the callback hostname and checks the resolved IP addresses again. If the hostname resolves to a blocked address, delivery is stopped before the outbound request is made.

Provider signatures are still the primary webhook security control. IP allowlisting can be useful for some customers, but it should not replace signature verification.

Syllecta does not currently offer a dedicated static outbound IP as part of the first production baseline. If your environment requires strict inbound allowlisting, raise that during onboarding so the workload can be reviewed before production traffic is sent.

See also: Provider verification matrix.

Encryption and Backups

Public browser and API traffic should use HTTPS/TLS.

Stored data lives in production databases, queues, volumes, and backups. Backup data must be treated with the same sensitivity as the primary database because it can contain operational metadata and, during the debug window, payload data.

Syllecta does not currently claim customer-managed-key encryption, audited backup isolation, or a formal restore SLA from public docs. Database/disk/backup encryption posture, backup access controls, retention, and restore-drill evidence must be confirmed in production readiness review and customer agreements before regulated workloads.

Audit and Incident Response

Audit logs are security evidence and are protected from generic operational cleanup.

Current and planned audit coverage should distinguish:

• login and auth-related events
• admin/support actions
• credential create, rotate, revoke, deactivate, and delete actions
• raw payload access
• payload search
• replay enqueue
• retention policy changes
• tenant or role changes

Suspected vulnerabilities should follow Vulnerability disclosure. Customer-impacting incidents should use the agreed pilot/support channel until binding support terms are finalized.

Compliance Status

Syllecta does not currently claim SOC 2 or ISO 27001 certification, HIPAA or PCI compliance, or GDPR compliance. Compliance packaging, DPA terms, and SOC 2 readiness are roadmap work for customer contracts and larger production pilots.

Do not treat early Syllecta environments as certified storage for regulated payloads unless a signed agreement and implementation review explicitly covers that workload.

For current design-partner review material, see Security review pack.

Pre-Production Checklist

Before sending real production traffic:

• Confirm which providers will send webhooks.
• Check whether provider-side payload minimization is available.
• Confirm whether raw replay is required.
• Choose a target payload policy: metadata only, redacted payload, or short raw debug window.
• Confirm expected payload size and volume.
• Confirm retention requirements.
• Rotate webhook secrets before launch.
• Confirm the production callback is a public HTTPS endpoint.
• Verify callback endpoint behavior under retries.
• Confirm expected webhook volume and payload size so ingress limits are sized correctly.
• Confirm who in your team should access event details and replay actions.

If a tenant is suspended, valid signed webhooks are acknowledged without callback delivery to avoid provider retry storms. Syllecta stores minimal event evidence only and does not keep the raw provider payload in that path. Repeated invalid signatures, stale timestamps, rejected replays, unsupported content types, malformed JSON, oversized bodies, and rate-limit events are emitted as structured security logs.

See Traffic protection for the current spike, abuse, replay, and dashboard query policy.

FAQ

Can we run without storing raw payloads?

Yes. Set the tenant payload policy to metadata_only. Syllecta will keep event metadata for observability, but payload body search and raw replay are unavailable because raw payloads are not stored.

Can support see raw payloads?

Support workflows should rely on tenant-scoped operational metadata and redacted views by default. Raw payload access is only meaningful for tenants using a raw debug window and should remain exceptional.

What can support see?

Support should work from tenant-scoped operational metadata and redacted views by default. Raw payload access should be exceptional, scoped to a reason, and audit logged.

Is redaction applied before storage?

Yes for redacted_payload tenants. metadata_only stores no payload body. raw_debug_window stores raw payload temporarily for replay, while dashboard views still use a redacted copy.

Are payloads used for billing?

Billing should rely on operational events and usage records, not raw payload content.

Do you support allowlisting?

Not as a default first-production feature. Signature verification should remain the primary security control. Dedicated/static outbound IP support is a later option for allowlisting-sensitive customers and should be discussed during onboarding.

Are you SOC 2, HIPAA, PCI, or GDPR compliant?

No formal SOC 2 or ISO certification, HIPAA or PCI compliance, or GDPR compliance claim is made today. The architecture is being shaped around data minimization, tenant isolation, retention, auditability, and clear customer responsibilities.