Would you put all API data into Redux?

No — not by default. Server data (see [client state vs server state](#what-is-the-difference-between-client-state-and-server-state)) has different needs than plain client state: caching, background refetching, deduplication of in-flight requests, invalidation, pagination, and loading/error tracking. Hand-rolling all of that inside Redux slices reinvents a data-fetching layer.

Guidance:

• Use RTK Query (or React Query/SWR) for server data — these libraries already integrate with the Redux store (RTK Query lives inside your Redux store) and handle caching/invalidation/refetching for you.
• Use plain Redux slices for genuine client state: UI state, auth/session flags, user preferences, multi-step form state, feature toggles — anything that isn't just a mirror of server data.
• Avoid duplicating server data into a separate hand-written slice "just in case" — it creates two sources of truth that can drift out of sync (e.g., a users slice updated manually alongside an RTK Query cache for the same endpoint).
• It's fine to combine both: e.g., store the *currently selected* item's ID in a normal slice, while the actual item data comes from an RTK Query/React Query cache keyed by that ID.

In short, Redux (or any store) is best reserved for state your UI truly owns; let a dedicated data-fetching layer own anything that mirrors the server.