I set the master branch to deploy an api to the production environment, and other feature branches to run tests on PR. But even after all unit tests succeed, it could cause an error during deployment or even after the api endpoints become live (for whatever reason).
So I was wondering if there is a way to ensure the code is successfully running live before it is merged into master. I know GitLab CICD allows it as shown in this doc about merging when pipeline succeeds.
A workaround I know is to create a testing environment to deploy and test the public endpoint tests. But it is very bothersome, since we are deploying on Kubernetes with a lot of secrets, configurations, and communications within the private networks.
I would greatly appreciate ideas and help! Thank you 
Either I’m not understanding your goal or you’re not following the GitLab feature correctly.
IIUC, you’re trying to make sure that your production system is functional before you merge the code into your mainline branch. In order to do that, you’d need to be doing your production deploys from your branches, running functional tests against your production system, and then merging afterwards and not deploying on your mainline branch (since whatever’s being merged will already have been deployed). I’m not aware of any common way of working that advocates doing your production deploys from feature branches.
At the same time the GitLab feature, IIUC, is meant to automate the merge of a PR that has no open work on it. I don’t use GitLab so forgive me if I’m wrong but it seems like a PR starts out with some number of open ‘threads’ which all have to be marked as resolved prior to an automated merge happening. Once there are no open ‘threads’ and the pipeline passes, then GitLab can merge the PR for you automatically. I’m not sure whether GitHub etc. has a feature like this but it might. If it doesn’t it seems like it should be semi-easy to automate from your CCI pipeline by having a key that has write access to the repo and doing the merge there with a [skip ci] commit message if you don’t want to trigger a workflow on the mainline branch.
But again this would be a highly unorthodox workflow (deploying your PRs to production on every change, validating that production works, and then merging to main). Most people instead either trust their unit tests to verify mergeability and their monitoring to verify that there hasn’t been a regression in production and they may go to the effort of setting up an integration environment that they deploy to first and run system tests against (although industry trends are moving towards testing in production rather than in a toy integration environment).
Now if you wanted to automatically roll a release back from a pipeline and you have automated smoke tests that you can run against the production environment then it should be trivial to add a post deploy step that runs the smoke tests and if they fail automatically triggers a rollback. But without the automated tests you’ll either have to manually verify production for each deploy and whack some sort of hold job in CCI or rely on vigilance (which isn’t a real strategy).
Hope that helps!