SoConnective — Documentation

Beyond features, SoConnective ships a set of non-functional requirements (NFRs) that keep the platform fast, safe, and observable. These are backed by Redis and surfaced to platform admins on the System Health board.

Rate limiting

Sensitive endpoints are rate-limited with a per-IP fixed window:

Login — roughly 10 requests/min
AI — roughly 30 requests/min

The limiter is deliberately fail-open: if Redis is unavailable, requests are allowed through rather than blocked. This guarantees a Redis outage can never lock users out — availability is favored over strict enforcement for these limits.

Read-through caching

Global catalogs are served through a read-through cache with a ~5-minute TTL:

Marketplace modules
Marketplace starter packs
Integration providers

On a cache miss the value is read from the source and populated into Redis; subsequent reads within the TTL are served from cache. These catalogs change rarely, so caching them removes repeated database work from hot paths.

Token metering and the soft cap

AI usage is metered per account, per month, recorded from Anthropic usage data. A soft monthly cap can be applied via AI_TOKEN_CAP_DEFAULT:

Set to a positive value → that is the default monthly token cap per account.
Unset or 0 → unlimited (no cap).

The cap is "soft": it exists to give visibility and control over spend per account. Metering applies to AI usage including the token-metered AI Operator (see AI architecture).

Error tracking

The platform keeps a recent-errors breadcrumb — a rolling record of recent errors — so operators can see what has been going wrong without digging through raw logs.

System Health board

All of the above is surfaced on the platform System Health board, giving platform admins a single operational view:

Token usage (per account, against any cap)
Recent errors (the breadcrumb)
Redis status
Connection statuses (integration/provider connectivity)

System Health is the at-a-glance answer to "is the platform healthy, and who is using what".