Security Best Practices for Custom Endpoints
When you connect Bounds to your own backend to perform actions - checking an order, fetching account details, submitting a form - you are extending your platform's reach into your own systems. These guidelines keep that connection safe.
Use a dedicated endpoint, not your main API
Create a separate API layer exclusively for Bounds-triggered requests. Do not route actions through your existing product API or admin endpoints. If a key is ever rotated or misused, a dedicated endpoint limits the blast radius to that one surface.
Only expose what is actually needed
Grant the minimum access required for the specific task. A status lookup does not need write access. An order check does not need access to account settings. Build each endpoint to do one thing well.
| Task | Recommended access |
|---|---|
| Answering from uploaded docs | No external calls needed |
| Checking order status | Read-only, scoped to current session user |
| Submitting a support ticket | Write-only to the support table |
| Fetching account details | Read-only, scoped to authenticated user |
| Updating a preference | Write-only to that field, nothing else |
Verify every incoming request
Bounds signs outbound action requests with your server-side key. Your endpoint must verify this on every request and reject anything that does not present a valid, current key. Do not rely on IP allowlisting as your only check.
Scope all responses to the current user
Never run bulk queries. Your endpoint should return only data that belongs to the user in the current session. Even if the underlying query could return more, it should not.
Treat message content as untrusted input
The text a user types is user input. Never pass it directly into a database query, shell command, or downstream API call without sanitising and validating it first.
HTTPS only
All custom endpoints must be served over HTTPS with a valid TLS certificate (1.2+). Plain HTTP endpoints will be rejected.
Log everything your endpoint does
Keep access logs for every action call: session ID, timestamp, action taken, response code. Set up alerts for anomalous volumes or repeated errors.
Rate limit your endpoint independently
Bounds applies session-level rate limits, but your endpoint should enforce its own as well. Use session ID as the rate limit key. Do not assume Bounds's limits are sufficient.