The answer depends on many other factors including the infrastructure. 

 1. Even POST requests can create unwanted changes in production DB so GET is mostly the only safe method, investigate if this is the case for your product.
 2. Do you have a staging server where you do rest of the use cases (if you plan to use only POST and GET in production)
 3. What is your team decision and what are their expectation
 4. What is the product structure, is there test sandbox that you can access from the production environment so that you won't affect real users
 5. What kind of product are you testing

So as in any test activity, the answer is:

 1. The approach is context depended
 2. You should have proper risk analysis on what happens if you don't test other http methods and stick to only http GET and POST
 3. Is there a backup or restore option if something goes wrong.

Sometimes you won't be able to get answers for all those questions due to immature project stakeholders and process. In that case, I would stick to the below procedures:

 1. Ensure to test all GET actions and validate the response schema
 2. Check authentication and authorization test for test users. Make sure your test accounts have limited authorization and the test accounts have access only to test data. Don't test admin account use cases as it can cause unwanted changes
 3. Don't use admin test accounts as account breaches can compromise the entire production environment
 4. Check production environment response time 
 5. Run postman monitor to ensure health of the production API
 6. Stay away from CRUD operations other than R (Read, means GET)
 7. Discuss with the team on other use cases and be clear on the risk involved