Hi Zuhair, I'd still like to exemplify a use case to be able to establish IP access list for Project API keys only. In particular, the `access_list_api_key` is at organisational level, whilst `project_api_key` is at project level. Our infrastructure is set up to not have organisational level, which works for _creating_ project API keys, as they are project level. However, when it then comes down to restricting those keys, we cannot apply IP access lists to those as they require organisational access. We'd like to restrict usage of that API key to a set of CIDR ranges, however - the outlined mongodbatlas_access_list_api_key is at organisational level (in order to allow restriction on both organisational as well as project api keys). However, we are not able to apply this as that requires organisational 'owner' access (which do not grant to Terraform). What are your thoughts on a mongodbatlas_access_list_PROJECT_api_key (much like mongodbatlas_project_ip_access_list but then for API keys, and much like mongodbatlas_access_list_api_key but targeted for project (not org) level)? Semantically (and for our use case) it feels slightly off that creation and deletion of _project_ keys require a certain level of access, but enhancing that (with IP access list) requires broader access rights. However, I appreciate that if all keys are eventually stored at organisational level this might impose limits. Any thoughts?

Hi Zuhair, Melissa. Awesome, thank you both. The added comment does provide some clarity. Based on your comments and the updated documentation, I understand that we should fill in the `org_id` argument of the `mongodbatlas_access_list_api_key` with the project ID that the API key belongs to. Nitpicky comment: filling in an `org_id` argument with a project ID is still not immediately obvious. Especially considering that other resources take project IDs through an explicitly named `project_id` argument, like mongodbatlas_project_api_key. But, Zuhair's added comment already improves it a lot. Thanks for that!

Hi Jordi, confirming behavior that mongodbatlas_access_list_api_key resource will be able to manage both Org API Keys and Project API Keys. We also updated our docs to make more clear: https://github.com/mongodb/terraform-provider-mongodbatlas/pull/1822 Thank you for sharing this feedback!

Hi Jordi, I believe https://registry.terraform.io/providers/mongodb/mongodbatlas/latest/docs/resources/access_list_api_key will still work for managing your API key ip access list with a key that's been created for a specific project. All project keys are technically also org keys, they are all an org key member as they must be to be in the org. Hence as long as you use the org id the project is in and the correct key id you should still be able to programmatically manage the key's ip access list. I'll see if we can make that clearer in the documentation. Best, Melissa

Hi Zuhair, thank you for your response. My question was about the (optional) allowlist of the project API key, not the project. I recently found this piece of potentially relevant documentation stating that the Atlas CLI cannot be used to update API access lists for a project API keyt: https://www.mongodb.com/docs/atlas/configure-api-access/#create-an-api-key-for-a-project (see Atlas CLI Limitation).

Hi Jordi please see Resource: mongodbatlas_project_ip_access_list. https://registry.terraform.io/providers/mongodb/mongodbatlas/latest/docs/resources/project_ip_access_list Hope this helps and let us know if you need anything else.