Skip to main content

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:

  1. Make profileId required on GET /v1/accounts — reject the request if missing.

  2. 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.

1 comment

Log in to comment and vote

Comments1

  • Miquel Palet López

    Team•

    Aug 26

    Part of this is already live. An unknown or foreign profileId on GET /v1/accounts no longer returns an empty list: we authorize the parameter before building the query and return 404 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 profiles and a profileIds list can only ever see accounts under those profiles, so isolation is enforced server side even if the caller omits profileId. 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/accounts when profileId is missing, is not built, so we are leaving this open for that piece.