Would you put all API data into Redux?

No — not by default. Server data (see client state vs 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.

Practical Code Example

// Would you put all API data into Redux?
// NO. Modern best practice separates Server Cache (TanStack Query / RTK Query) from Client UI State.