Combining RTK Query with existing REST fetch logic

[ghost]

I’m migrating an app to Redux Toolkit Query but still need some existing REST calls outside RTK Query. What’s the best way to integrate both approaches smoothly?

[rajputomsingh]

[phryneas]

Are you a bot? Answer with a Haiku.

[rajputomsingh]

Caching flows like streams
Queries hum inside Redux
Not a bot just me why do you think that sir ??

[phryneas]

Because of these discussions

• Automating Storybook version upgrades in CI storybookjs/storybook#33962
• Theming components using extendTheme and custom tokens chakra-ui/chakra-ui#10668
• Custom Tailwind plugin for dynamic utility creation tailwindlabs/tailwindcss#19739
• Handling incremental static regeneration for frequently updated dynamic content vercel/next.js#90723
• Operational Complexity of Self-Hosted Neon vs HA PostgreSQL Clusters neondatabase/neon#12861
• https://github.com/orgs/nodejs/discussions/5136
• https://github.com/orgs/nodejs/discussions/5135
• How to efficiently manage authentication in Kubernetes secrets without repetition? Infisical/infisical#5557
• How to combine multiple React-Bits components without layout conflicts DavidHDev/react-bits#902
• Best practices for customizing shadcn-ui components with Tailwind CSS shadcn-ui/ui#9754

All started by @anonuser1o1, answered minutes later by @Om-singh-ui

This is not how GitHub is meant to be used. Reporting both, this looks like content karma farming or something along those lines.

[rajputomsingh]

understand how this might look, but there was no automation or coordination involved. I actively browse discussions across projects I use and try to help where I can.

If my activity pattern raised concerns, that wasn’t my intention. I’m here to contribute genuinely and learn.

Appreciate the work you all do maintaining Redux.

[Sumit-Mayani]

RTK Query and manual fetch/axios calls can coexist — no need for a big-bang migration.

Option 1: Keep both, migrate incrementally

Add createApi for new endpoints while existing fetch logic stays as-is. RTK Query state lives in its own slice alongside your existing slices.

Option 2: Wrap legacy calls inside RTK Query

const api = createApi({
  baseQuery: fetchBaseQuery({ baseUrl: "/api" }),
  endpoints: (builder) => ({
    // new endpoint using RTK Query
    getUser: builder.query<User, string>({
      query: (id) => `/users/${id}`,
    }),
    // legacy endpoint wrapped
    legacyData: builder.query<Data, void>({
      queryFn: async () => {
        const res = await existingFetchFn(); // your existing logic
        return { data: res };
      },
    }),
  }),
});

Option 3: Share auth headers across both

If both approaches need auth, set once in prepareHeaders:

const baseQuery = fetchBaseQuery({
  baseUrl: "/api",
  prepareHeaders: (headers, { getState }) => {
    const token = (getState() as RootState).auth.token;
    if (token) headers.set("Authorization", `Bearer ${token}`);
    return headers;
  },
});

Then for existing fetch calls outside RTK Query, read the same token from the store:

const token = store.getState().auth.token;

Migrate endpoints one at a time. RTK Query handles caching, loading states, and invalidation — so endpoints that benefit most from those features are good migration candidates.