Prove a phone can reach your API
https://patrickz.ai/learn/mobile-api-proof/

OUTCOME
Retire connectivity uncertainty before adding an AI feature.

STACK
FastAPI · Docker · Expo

YOU NEED
A coding agent, a physical phone that can reach your computer (same network or a temporary tunnel), and the stack the steps name: Python with FastAPI, Docker, and Node.js with Expo. Another API framework or mobile client works if you adapt the steps. Use no personal or employer data.

1. Set your boundary
Keep the first version to one health endpoint and one phone screen with a Test connection button that shows the response or a readable error. Add authentication, data and AI only after a physical phone passes that test.

2. Create a health endpoint
Create a FastAPI /healthcheck endpoint that returns harmless data.

3. Run the API in Docker
Run the API in Docker, then call the health endpoint from your computer before trying the phone.

4. Add a Test connection screen
Create an Expo screen with a “Test connection” button.

5. Test on a physical phone
Test on a physical phone, over the same network or a temporary tunnel. Close the tunnel afterwards.

6. Type responses and show errors
Add typed API responses and visible error states, including when the API is stopped.

LATER (NOT TODAY)
- Authentication and storage: Add authentication and data storage.
- AI for one decision: Add AI only when a specific user decision requires it.

PROMPT
Help me prove a physical phone can reach my API, in a new practice folder, with FastAPI, Docker and Expo. Keep the first version to one health endpoint and one phone screen with a Test connection button that shows the response or a readable error. No authentication, data storage or AI yet, and no secrets in the client. List the setup commands before changing any files. Then work in five checkpoints and, after each, tell me how to check it:
1. A FastAPI health endpoint.
2. The API running in Docker.
3. An Expo screen with a Test connection button.
4. A test on the physical phone over [the same network or a temporary tunnel], never localhost.
5. Typed API responses and a visible error when the API is stopped.
My computer’s development address: [IP address or tunnel URL].

FOLLOW-UP PROMPT
Review this phone-to-API proof. Check that the development address is configurable rather than hard-coded to localhost, the stopped-API error is readable on the phone, responses are typed on both sides, no secret or tunnel URL is bundled into the client, and any temporary tunnel is closed after testing. List each gap and the test that catches it.

EXAMPLE / EXPERIMENT
Create a harmless health endpoint. Call it from the physical phone, then stop the API and verify a useful error. Restore the service and retry.

CHECK YOUR RESULT
[ ] A real phone receives the expected response.
[ ] An unavailable API produces an understandable error.
[ ] No secret is bundled into the client.

IF IT FAILS
localhost on a phone means the phone, not your development computer. Use an explicitly configured development address and close any temporary public tunnel after testing.

MY RESULT / NEXT CHANGE