You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs(synapse): fix config schemas, add guardrails page, correct health responses
Config examples now match actual Rust structs: rate limiting under
[server.rate_limit], telemetry using [telemetry.exporter] with protocol
field, auth via api_url+gateway_secret (not static keys/JWT), routing
with correct field names. Added NVIDIA provider, guardrails doc page,
and fixed health endpoint response formats.
Copy file name to clipboardExpand all lines: content/docs/grid/synapse/api.mdx
+6-2Lines changed: 6 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -328,13 +328,17 @@ Response:
328
328
329
329
## GET /health
330
330
331
-
Health check endpoint. No authentication required.
331
+
Health check endpoint. No authentication required. The gateway binary listens on port 3000 by default; Docker Compose maps host port 6000 to container port 3000.
Copy file name to clipboardExpand all lines: content/docs/grid/synapse/authentication.mdx
+37-47Lines changed: 37 additions & 47 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,7 +7,7 @@ Synapse supports multiple authentication methods to secure access to its API end
7
7
8
8
## API Key Authentication
9
9
10
-
The default authentication method. Clients pass an API key in the request header, and Synapse validates it against the configured key store.
10
+
The default authentication method. Clients pass an API key in the request header, and Synapse validates it by calling the synapse-api service's `/internal/resolve-key` endpoint.
|`api_url`| URL of the synapse-api service | -- (required) |
40
+
|`gateway_secret`| Shared secret for gateway-to-API authentication | -- (required) |
41
+
|`cache_ttl_seconds`| How long to cache resolved API keys | 30 |
42
+
|`cache_capacity`| Maximum number of cached key resolutions | 10000 |
43
+
|`public_paths`| Paths that skip authentication |`["/health"]`|
44
+
|`tls_skip_verify`| Skip TLS verification for API calls (dev only) | false |
45
+
36
46
<Callouttype="warning">
37
-
Always use environment variable interpolation for API keys. Never hardcode secrets in config files.
47
+
Always use environment variable interpolation for the gateway secret. Never hardcode secrets in config files.
38
48
</Callout>
39
49
40
-
### Key Validation
50
+
### How It Works
41
51
42
-
When Synapse runs alongside the Omni API (synapse-api), keys are validated against the API's key store. This enables per-key rate limits, usage tracking, and key rotation without restarting Synapse.
52
+
When a request arrives with an API key, Synapse calls synapse-api's `/internal/resolve-key` endpoint (authenticated with `gateway_secret`) to validate the key and resolve the associated client identity. Resolved keys are cached locally for `cache_ttl_seconds` to avoid per-request API calls.
43
53
44
-
## OAuth2 / JWT
54
+
The synapse-api can push cache invalidations to the gateway via the `/internal/invalidate-key` endpoint when keys are rotated or revoked.
45
55
46
-
For applications that use OAuth2 or JWT-based authentication, Synapse can validate tokens against a JWKS endpoint.
56
+
### BYOK Vault Integration
47
57
48
-
### Configuration
58
+
When configured, Synapse resolves BYOK (Bring Your Own Key) provider keys from a Gatekeeper vault instead of the synapse-api database:
Synapse caches the JWKS response and refreshes it periodically. Tokens are validated for signature, expiry, issuer, and audience.
74
-
75
68
## CSRF Protection
76
69
77
70
Synapse includes CSRF protection for browser-based clients.
@@ -81,10 +74,10 @@ Synapse includes CSRF protection for browser-based clients.
81
74
```toml
82
75
[server.csrf]
83
76
enabled = true
84
-
token_header = "X-CSRF-Token"
77
+
header_name = "X-Synapse-CSRF-Protection"
85
78
```
86
79
87
-
When enabled, non-GET requests from browser clients must include a valid CSRF token in the configured header. Tokens are issued via a dedicated endpoint or embedded in the initial page load.
80
+
When enabled, non-GET requests from browser clients must include a valid CSRF token in the configured header.
88
81
89
82
<Callouttype="info">
90
83
CSRF protection is primarily relevant when Synapse is accessed directly from a browser. API clients using `Authorization` headers are not affected.
@@ -98,11 +91,13 @@ Synapse tracks which client is making each request for usage analytics and rate
98
91
2.**JWT claims** -- `sub` or `client_id` claim
99
92
3.**IP address** -- fallback when no other identifier is available
100
93
101
-
### Custom Client Header
94
+
### Custom Client Identification
95
+
96
+
Client identification is configured separately under `[server.client_identification]`:
102
97
103
98
```toml
104
-
[auth]
105
-
client_id_header = "X-Client-Id"
99
+
[server.client_identification]
100
+
header_name = "X-Client-Id"
106
101
```
107
102
108
103
When set, Synapse uses the value of this header as the client identifier, regardless of the authentication method.
@@ -119,14 +114,9 @@ When set, Synapse uses the value of this header as the client identifier, regard
119
114
120
115
## Unauthenticated Endpoints
121
116
122
-
The following endpoints do not require authentication:
123
-
124
-
-`GET /health` -- health check
125
-
-`GET /v1/models` -- model list (configurable, can require auth)
126
-
127
-
To require authentication on all endpoints:
117
+
Paths listed in `public_paths` skip authentication. By default, only `/health` is public:
The health endpoint is always available at `GET /health` and returns `ok` (plain text) when the server is ready.
27
+
The health endpoint is enabled by default at `GET /health` and returns `ok` (plain text) when the server is ready. The path and enabled state are configurable:
28
+
29
+
```toml
30
+
[server.health]
31
+
enabled = true
32
+
path = "/health"
33
+
```
26
34
27
35
### CORS
28
36
@@ -39,7 +47,7 @@ max_age = 3600
39
47
```toml
40
48
[server.csrf]
41
49
enabled = true
42
-
token_header = "X-CSRF-Token"
50
+
header_name = "X-Synapse-CSRF-Protection"
43
51
```
44
52
45
53
## Environment Variable Interpolation
@@ -69,28 +77,68 @@ See [synapse.omni.dev/pricing](https://synapse.omni.dev/pricing) for current pla
69
77
70
78
## Rate Limiting
71
79
72
-
### In-memory
80
+
Rate limiting lives under `[server.rate_limit]`. It supports global and per-IP request limits with either in-memory or cache-backed (distributed) storage.
81
+
82
+
### In-memory (default)
73
83
74
84
```toml
75
-
[rate_limit]
76
-
backend = "memory"
77
-
requests_per_minute = 60
78
-
burst = 10
85
+
[server.rate_limit]
86
+
87
+
[server.rate_limit.storage]
88
+
type = "memory"
89
+
90
+
[server.rate_limit.global]
91
+
requests = 60
92
+
window = "1m"
79
93
```
80
94
81
-
### Redis
95
+
### Cache-backed (distributed)
82
96
83
97
```toml
84
-
[rate_limit]
85
-
backend = "redis"
86
-
redis_url = "{{ env.REDIS_URL }}"
87
-
requests_per_minute = 120
88
-
burst = 20
89
-
key_prefix = "synapse:rl:"
98
+
[server.rate_limit]
99
+
100
+
[server.rate_limit.storage]
101
+
type = "cache"
102
+
url = "{{ env.VALKEY_URL }}"
103
+
pool_size = 10
104
+
connect_timeout = 5
105
+
106
+
[server.rate_limit.global]
107
+
requests = 120
108
+
window = "1m"
109
+
110
+
[server.rate_limit.per_ip]
111
+
requests = 30
112
+
window = "1m"
90
113
```
91
114
115
+
### Token-based rate limits
116
+
117
+
For LLM token budgets, configure `[server.rate_limit.tokens]`:
0 commit comments