iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
If this is a React app and an API request starts in useEffect, React Strict Mode may be making the request appear twice during development. That is a diagnostic behavior, not a production feature. If duplicate calls also happen in production, investigate the Effect’s dependencies, component remounts, and the request flow instead of blaming Strict Mode.
Why an API request can run twice in React
React’s official documentation says that when root-level Strict Mode is enabled, React runs an extra Effect setup-and-cleanup cycle before the first real setup in development. This helps reveal Effects that do not clean up correctly. React says these checks do not affect production builds. See React’s StrictMode reference.
For an Effect that fetches data, the development sequence can start one request during the extra setup and another during the real setup. Cleanup may stop work that is still in progress when the request API and code support cancellation, but it cannot erase a request the server has already received or processed. A cancelled request may therefore still appear in server logs or have caused a server-side effect.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsHow to diagnose duplicate requests
- Compare development with production. Check the browser’s Network panel in both. A duplicate seen only in development is consistent with Strict Mode replay; a duplicate in production needs a separate explanation.
- Check the Strict Mode boundary. Look for a root-level
<StrictMode>wrapper. React’s development-only replay described here is associated with Strict Mode at the root. - Inspect the Effect dependencies. React also reruns an Effect when a dependency changes. Review the dependency array and the values it contains; a request may be repeating because state, props, or another dependency changes.
- Look for genuine remounts. Routing, conditional rendering, or state-driven tree changes can remove and recreate a component, causing its Effect to run again.
- Follow the request’s trigger. Determine whether the request is a read started by an Effect or a write that should happen only after a user action.
React’s troubleshooting guidance addresses the question “My Effect runs twice when the component mounts” and distinguishes Strict Mode’s extra development cycle from ordinary Effect reruns: Synchronizing with Effects.
#1 Best Overall
What to do for data-fetching requests
Use cleanup for work that can be stopped
Effects that establish a connection or subscription should return cleanup that disconnects or unsubscribes. For a fetch, use the cancellation mechanism supported by the request code when appropriate. Cleanup is for stopping or undoing external work where possible; it is not a guarantee that a server never received a request.
Deduplicate and cache reads when appropriate
If equivalent reads can overlap or recur, a request cache or data-fetching layer can deduplicate in-flight requests and reuse cached responses according to the application’s freshness needs. React’s documentation identifies deduplication, caching, and avoiding network waterfalls as capabilities a data-fetching solution can provide, but its cited pages do not recommend a particular library. See React’s discussion of fetching data with Effects.
Strict Mode is useful here: it exposes code that assumes an Effect runs only once. Treat the replay as a prompt to make the read and its cleanup robust, rather than as a reason to suppress React’s development checks.
What to do for writes and user actions
Start mutations in the event handler
Actions such as buying something, sending a payment, or creating a record in response to a click or form submission belong in the corresponding event handler, not in an Effect that reacts to component mounting. The handler ties the request to the user action instead of the component’s lifecycle. React explains this distinction in Synchronizing with Effects.
Make retries safe with provider-supported idempotency
A timeout or lost response can leave the client unsure whether a write succeeded. Retrying blindly may perform the operation twice. When the API provider supports idempotency, follow its documentation for sending an idempotency key and for that provider’s key scope and retention rules. Stripe documents its idempotency support as a way to retry requests safely without accidentally performing the same operation twice: Stripe API idempotent requests. Do not assume another provider uses the same semantics.
The IETF HTTPAPI Idempotency-Key header document is an Internet-Draft, not a finalized standard. Its status and details may change.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choose the fix that matches the cause
| What you observe | Likely area to investigate | Useful response |
|---|---|---|
| Extra call only in development with root-level Strict Mode | Strict Mode’s Effect setup-and-cleanup replay | Make cleanup correct; for reads, consider request deduplication or caching. |
| Calls recur when props or state change | Effect dependencies | Review which values the Effect depends on and whether the request belongs in an Effect. |
| Calls recur after navigation or conditional rendering | Component remounts | Trace what removes and recreates the component and why. |
| Duplicate call also occurs in production | Application request flow, dependencies, retries, or remounts | Trace the trigger and network timeline; do not attribute it automatically to Strict Mode. |
| A user action creates or changes server data | Mutation triggered by lifecycle or retried after uncertainty | Use an event handler and, where available, the provider’s documented idempotency mechanism. |
Should you turn off Strict Mode?
Do not use disabling Strict Mode as the fix for duplicate requests. It can hide the development signal without addressing dependency-driven reruns, remounts, unsafe mutation placement, or production duplicates. Diagnose which request is repeating and apply the remedy for that failure mode.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
