Customer data protection

Customer security answer

Syllecta uses operational metadata first: provider, event id, event type, delivery status, timing, callback endpoint, retry/replay state, failure reason, and correlation ids. That is the data needed for routine observability, recovery, and support.

Payload content should be treated as temporary debug/replay data. Customers should avoid sending card data, passwords, access tokens, session cookies, long-lived secrets, full customer profiles, or unnecessary personal data.

Current controls include provider verification, tenant-scoped access, HTTPS callback policy, private-network egress blocking, redacted dashboard views, and operational retention cleanup. Roadmap controls are clearly marked below instead of being presented as already shipped controls.

Data exposure model

Syllecta works from operational metadata first: provider, event id, delivery status, timestamps, retry state, callback result, failure reason, and correlation ids. That data is usually enough to answer the first operational question: what arrived, where it went, and why it failed.

Payload content is treated as debug and replay data, not as the primary product record. Dashboard views are redacted for routine triage, and tenant-level controls can store metadata only, a redacted payload copy, or a short raw debug window for replay.

Current implementation

• Tenant-aware authentication for console access and API usage.
• Provider signature verification for supported webhook integrations.
• Production callback URL validation for HTTPS-only public destinations.
• Pre-delivery DNS/IP checks that block private, loopback, and link-local callback targets.
• Redacted dashboard payload views for sensitive-looking headers and fields.
• Restricted internal access to raw payload data for replay/debug flows.
• Retention cleanup for webhook event and payload history.
• Rate limiting on login attempts and protected Backoffice API routes.
• Webhook ingress body caps, content-type validation, malformed payload rejection, rate limits, and structured security events.
• App-level scanner-path rejection, request/body timeouts, private no-index headers, replay throttles, and dashboard query bounds.

Secrets and credentials

API keys and webhook secrets are tenant security credentials, not support conversation data. The expected rotation path is to create or enter a replacement credential, update the provider or application, verify traffic, and revoke or deactivate the old value.

API keys are one-time reveal and stored as hash-backed records. Webhook provider secrets are masked in the UI, rejected when obviously weak, encrypted at rest for new writes, and exposed only to the internal verification path. Credential changes are recorded in audit logs. Dual-secret overlap is the next rotation improvement.

What customers should avoid sending

Webhook payloads should not include card numbers, passwords, access tokens, long-lived secrets, session cookies, or unnecessary personal data. If a provider sends sensitive fields by default, prefer provider-side field minimization where available and use Syllecta redaction/retention controls as an additional safety layer.

Access boundaries

Tenant users can only access their tenant's operational data. Admin and support access is intended for operational recovery, billing support, and security response, with audit logging required for privileged actions. Raw payload access should be treated as exceptional and limited to replay/debug workflows.

Callback egress

Provider signatures remain the primary webhook security control. Production callback URLs must use HTTPS and cannot target localhost, private networks, link-local addresses, or reserved IP ranges. Syllecta also checks DNS results before delivery so a public hostname cannot resolve to an internal address at send time.

A dedicated static outbound IP is not part of the first production baseline. Customers who require strict destination allowlisting should raise that during onboarding so the workload can be reviewed before production traffic is sent.

Encryption and backups

Public browser and API traffic should use HTTPS/TLS. Stored data lives in production databases, queues, volumes, and backups, so backup data must be treated with the same sensitivity as the primary database.

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

Retention

Raw webhook payloads are temporary operational data, with a short default debug window. Webhook metadata, synthetic events, simulations, job history, and reconcile diagnostics have separate operational retention classes. Financial ledger records, invoices, audit logs, tenant records, users, API keys, webhook secrets, settings, and plans are protected from generic cleanup and require separate legal/accounting or offboarding decisions.

Tenant payload policy can be metadata-only, redacted payload, or short raw debug window. Raw replay is only available when the selected policy keeps raw payload data inside the configured debug window.

Hardening roadmap

• Broader audit events for raw payload access, support access, and retention changes.
• Managed edge/WAF traffic protection for the public web, Backoffice API, and Cloud API surfaces as public traffic grows.
• Dedicated/static outbound IP options for allowlisting-sensitive customers.
• Customer-specific security questionnaires, DPA terms, and compliance review for larger regulated deployments.

Audit logging and incidents

Audit logs are treated as security evidence and are protected from generic operational cleanup. Replay requests are audit logged, and broader audit coverage for raw payload access, payload search, support access, credential changes, and retention policy changes is part of the hardening roadmap.

Suspected vulnerabilities should be reported through the documented vulnerability disclosure path. Customer-impacting incidents should use the agreed pilot or support channel until formal support terms are finalized.

Compliance status

Syllecta is not currently claiming SOC 2 or ISO 27001 certification, HIPAA or PCI compliance, or GDPR compliance. Compliance packaging, DPA terms, and SOC 2 readiness are planned as the product moves from early controlled use toward broader production use. Security claims on this page describe current implementation or clearly marked roadmap work.

More detail

See the public guide for a deeper breakdown of payload handling, storage modes, retention, and customer responsibilities: Security and data protection. Traffic spike and abuse behavior is documented here: Traffic protection. The retention matrix is documented here: Data retention. Design partners can use the Security review pack for the current questionnaire baseline and pre-pilot limits.

Security reports

If you believe you found a vulnerability, follow the Vulnerability disclosure process. Include the affected route, reproduction steps, and potential impact.