Guide: Traffic Protection

Syllecta separates abuse controls from normal usage limits. The goal is to make bad or accidental traffic cheap to reject, while approved high-volume webhook traffic can still be accepted, queued, and processed predictably.

What Happens First

Public traffic is classified before expensive work:

obvious scanner paths such as /.env, /.git, /wp-*, /swagger, /graphql, and registry/debug probes get a fast generic 404;
API responses include browser hardening headers and private console/admin surfaces are marked noindex;
Cloud API and Backoffice API enforce body-size caps, request timeouts, connection timeouts, and keepalive timeouts;
webhook ingress applies content-type, body-size, malformed JSON, provider signature, replay, and rate-limit checks before creating queue jobs.

Invalid or unknown traffic should not create webhook events, queue jobs, billing rows, or dashboard noise.

Webhook Spike Behavior

Valid signed webhook traffic is handled differently from forged traffic.

Traffic state	Behavior
Valid active tenant	Accept after durable validation/dedupe and enqueue delivery work.
Valid but suspended/past-due tenant	Acknowledge without callback delivery to avoid provider retry storms.
Invalid signature or stale timestamp	Reject cheaply and emit a security event.
Oversized or malformed payload	Reject before storage/forwarding.
Provider retry storm	Prefer queue/backpressure and tenant visibility over immediately forcing provider retries.

For very large planned spikes, the limit should be sized per tenant/provider instead of relying on one global cap.

Manual Replay

Manual replay is guarded separately because it can amplify traffic. Replay actions require normal tenant/admin access, use stored raw payload only when the tenant policy allows it, are audit logged, and have per-actor and per-tenant rate limits.

Dashboard Query Bounds

Dashboard/API reads use pagination and date-range bounds. Webhook event and observability range queries are capped to protect shared database capacity, while payload search is narrower because it is more expensive and only searches redacted payload views.

High-Volume Onboarding

Before sending high-volume production traffic, confirm:

expected steady RPS and burst RPS;
provider mix and webhook event types;
maximum payload size;
raw payload policy and retention window;
callback endpoint capacity and timeout behavior;
acceptable backlog and alert thresholds;
whether a dedicated capacity review or WAF/CDN rule is needed.

Emergency Mode

During an active incident, operators may temporarily pause a tenant, reduce delivery concurrency, or return 429/503 on selected paths. Those actions should be time-limited, recorded in incident notes, and communicated to affected tenants because some providers will retry aggressively.