Stricter profileId scoping option for single-key multi-tenant SaaS
For reseller/SaaS setups running many profiles under one API key, profileId on GET /v1/accounts is currently an optional filter — omitting it returns all accounts across the key, and an unknown profileId silently returns an empty list. That makes profile isolation entirely client-enforced.
Requesting an account-level opt-in for a hard server-side boundary, specifically:
Make profileId required on GET /v1/accounts — reject the request if missing.
Return an error on an unknown/invalid profileId instead of an empty list.
This would give defense-in-depth for anyone building multi-tenant on a single key, rather than relying solely on always-pass-the-right-id + re-filter on our side.
Log in to comment and vote
Comments1
Miquel Palet López
Aug 26
Part of this is already live. An unknown or foreign
profileIdonGET /v1/accountsno longer returns an empty list: we authorize the parameter before building the query and return404 Profile not found or access denied, so a wrong id fails loudly instead of silently.For the hard boundary itself, the supported pattern today is profile-scoped API keys. A key created with scope
profilesand aprofileIdslist can only ever see accounts under those profiles, so isolation is enforced server side even if the caller omitsprofileId. That is stronger than a required parameter, since a required id on a full-scope key still lets any of your own profiles be passed.The specific opt-in you asked for, a per-key flag that rejects
GET /v1/accountswhenprofileIdis missing, is not built, so we are leaving this open for that piece.