A deployment smoke test should answer whether the new application can perform a small important task. It should not create random follows or change a real listener's progress every time code is released.
Choose a narrow read-only operation from the documented API. Keep the request bounded and the assertion resilient to ordinary catalog changes.
Test the path that matters
A successful health response from your own web server does not prove that its podcast API connection works. A useful smoke test can call your deployed backend route, verify a controlled response shape, and confirm that authentication succeeds at the intended boundary.
Avoid asserting that a search returns exactly ten named shows forever. Catalog content and ordering can change. Check the fields your screen requires, the absence of an application error, and a reasonable response deadline.
Use a dedicated limited credential where your provider supports it. Keep authorization headers out of CI logs, including the command printed before a shell step runs.
Separate deeper checks
State-changing integration tests belong in a controlled test environment with explicit fixture ownership and cleanup. If a production write check is genuinely necessary, use a dedicated synthetic account and an exact cleanup rule, with the same care you would give a small migration.
Record the deployment version, test time, endpoint category, and outcome. That is enough evidence for a release note without storing a secret or a real person's listening data.
Run the smoke test after the new deployment is actually serving traffic. Testing an old pod during a rolling update can create a green result for code that has not finished starting.