This is a well-worn path.
If there is an API key lifetime restriction, it is always set by the API provider side. The security team stipulates a standard that says "developers who use our APIs must rotate their credentials, at least every 180 days" or something like that.
And in Apigee, you can provision credentials with a fixed lifetime. You can say "I want this to expire on Sept 30th" or "I want these credentials to expire in exactly 120 days". All of this is possible today.
The philosophy is not that The API producers, provision keys and then hand them out. That would be insecure. So it's API _consumers_ that visit the API catalog website, and provision their own credentials. An API Provider might _approve_ that request, but the API provider is not involved in generating credentials or distributing them, like via email or something. Provisioning and distribution is done via the devportal, secure by TLS and a devleoper sign-in.
The thing that ISN'T completely solved out of the box is, _managing_ the rotation. Ideally there ought to be a notification sent out to developers telling them "your credentials will expire in 30 days" or "... in 15 days" or "... in 3 days". Etc, with instructions for how to provision new credentials. Basically a link to the devleoper portal that allows them to get new credentials. This scan+notification system is not built in to Apigee.
Customers have often built these, themselves. Years ago, a customer I worked with built a cron-job that ran nightly and checked pending expiration, and sent emails out. These days, we have used App Integration as a way to scan an Apigee org for "about to expire" credentials, and then sent email to the developer registered for those credentials. Customers could also build something in Python that uses the Apigee API to perform a scan, and send an email, ... they'd need to install that Python thing as a Cloud Run Job that runs on a schedule.
So, there are various options out there.