Why state matters
A real person has a consistent session - same browser, same IP, same cookies - from the moment they log in until they leave. Sites treat that consistency as a sign of trust. So a session that suddenly swaps its IP or fingerprint halfway through looks like a bot. Stateless scraping also breaks any step that depends on the one before it: logged-in pages, shopping cart flows, forms protected by CSRF tokens (one-time anti-forgery codes), and paginated lists that track your place using cookies.
How stateful APIs implement it
A stateful scraping API gives you a session ID - a handle that ties your requests together. Your first request creates the session: it assigns a sticky IP (one that stays put), a consistent fingerprint, and an empty cookie jar. Every later request that sends the same session ID reuses all of that. Sessions have a TTL (time to live - how long before they expire), usually 10 minutes to a few hours; after that the session is gone and you start over. Some APIs let you keep a session alive indefinitely for a per-session fee.
When you do NOT need state
Public listing pages, product detail pages, blog posts, and most SEO crawl targets are stateless - each request works fine on its own. Stateless requests are cheaper (no session fee, and the IP can rotate freely) and easier to run in parallel. Use state only where the flow actually requires it, and default to stateless for everything else.