When the client performs a state-changing action, design the API contract so it can be completed in as few requests as possible—prefer batch-capable endpoints and responses that include what the client needs to update UI/state without additional “refresh” calls. Also, for one-way boolean updates where the server can infer intent, avoid unnecessary request bodies.

Apply this as follows:

• Prefer server-side batching: if the client currently loops per item (and adds delays/rate-limit workarounds), provide an endpoint that accepts an array of IDs.
• Avoid client re-fetches after mutations: don’t call a broad “fetch user/account” just to learn the mutation result; return the updated/derived data from the mutation endpoint.
• Simplify one-way updates: if an endpoint always sets a field to a constant (e.g., true), don’t require a payload that just repeats that constant.

Example (batch endpoint shape):

// Instead of calling per block with rate-limit delays
// await deleteResetModule({ blockId: currentBlock }) in a loop

// Prefer one request with all IDs
await deleteResetModules({ blockIds: blockIds });

Example (mutation returns data to update client state):

const res = await resetModule({ moduleId });
// res should include the updated state the UI needs
setStateFromResponse(res);
// Don’t call a separate fetchUser() just to refresh UI.