Timeout Support for API Requests

[hannah-mnq]

Tell us about the task you want to perform and are unable to do so because the feature is not available

When testing APIs that return responses after a delay (for example:
https://httpstat.us/200?sleep=15000), API Dash fails with a low-level ClientException without providing any control over how long the request should wait or a clear indication that the failure was due to a timeout.

Currently:

• There is no way to configure a request timeout duration.
• Slow but valid APIs may be interpreted as failed requests.
• The error message shown is technical and not clearly associated with a timeout.
• There is no option to cancel an in-progress request.

This makes it difficult to reliably test APIs that legitimately require more time to respond.

---

Describe the solution/feature you'd like us to add

Introduce request timeout handling with the following behavior:

• A global default timeout value configurable in settings.
• An optional per-request override when required.
• A clear timeout message such as:

  "Request timed out after X seconds."

• Optional ability to cancel an ongoing request.

The default timeout can remain at a sensible value so that existing workflows are not affected unless users choose to modify it.

---

Any other feedback you would like to provide regarding the site

API Dash already provides a clean and intuitive API testing experience. Adding proper timeout handling would significantly improve reliability and clarity when working with slow or unpredictable APIs.

I would appreciate hearing the maintainers’ thoughts on whether this aligns with the project roadmap before exploring implementation.

[ItzSouraseez]

@hannah-mnq @animator I believe this could be a better option to go for:
Per-Request Timeout UI

There could be two approaches for per-request timeout override:
Option A: Add a timeout field in the request editor UI (visible to all users)
Option B: Use request metadata/advanced settings (less cluttered, power users only)

[hannah-mnq]

@hannah-mnq @animator I believe this could be a better option to go for: Per-Request Timeout UI

There could be two approaches for per-request timeout override: Option A: Add a timeout field in the request editor UI (visible to all users) Option B: Use request metadata/advanced settings (less cluttered, power users only)

Thanks for the suggestion @ItzSouraseez . I agree that a per request timeout configuration makes more sense than relying only on a global setting.

Both approaches you mentioned look reasonable. Option B, using advanced settings or request metadata, feels like a good balance from a UX point of view since it keeps the main interface clean while still giving flexibility to users who need it. That said, I am happy to follow whichever approach the maintainers feel fits best with API Dash’s overall direction.

Looking forward to @animator’s guidance on this. Once the direction is clear, I would be glad to take this up and work on the implementation.

[animator]

Start with a default timeout field in Settings. Then more advanced per request feature can be added.

[hannah-mnq]

Start with a default timeout field in Settings. Then more advanced per request feature can be added.

@animator Thanks for the guidance, that makes sense. Starting with a default timeout field in Settings sounds like a good first step. I will proceed with this approach and focus on implementing that first, and we can add per-request support later.
Also, please let me know if there are any preferences around default values or validation.

[Riddesh12]

Wrap API calls with a timeout

Catch timeout exceptions separately

Show a custom timeout message

Abort the request if canceled

[Januda-lelwala]

Just tested with a real 30-second delayed response using Beeceptor (configured delay: 30s).
API Dash waited the full ~31 seconds and returned 200 OK successfully — no ClientException.

For comparison:
-httpbin.org/delay/30 → caps at ~10s delay, but also works fine.
-httpstat.us/200?sleep=15000 → fails with empty reply even in curl (server-side quirk, not client timeout).

This suggests the Dart http package (used by API Dash) has no short default read/overall timeout — requests can run for 30+ seconds without failing.So the original failure was likely specific to httpstat.us's unusual "no response ever" behavior, not a general app limitation.That said, adding configurable timeouts (global + per-request), clear timeout error messages, and request cancel would still be super useful for:

1)Enforcing limits when desired
2)Better UX on very long requests
3)Handling rare stalled connections

Happy to close this if the maintainers think it's not needed, or keep it open for the enhancements!

[hannah-mnq]

Just tested with a real 30-second delayed response using Beeceptor (configured delay: 30s). API Dash waited the full ~31 seconds and returned 200 OK successfully — no ClientException.

For comparison: -httpbin.org/delay/30 → caps at ~10s delay, but also works fine. -httpstat.us/200?sleep=15000 → fails with empty reply even in curl (server-side quirk, not client timeout).

This suggests the Dart http package (used by API Dash) has no short default read/overall timeout — requests can run for 30+ seconds without failing.So the original failure was likely specific to httpstat.us's unusual "no response ever" behavior, not a general app limitation.That said, adding configurable timeouts (global + per-request), clear timeout error messages, and request cancel would still be super useful for:

1)Enforcing limits when desired 2)Better UX on very long requests 3)Handling rare stalled connections

Happy to close this if the maintainers think it's not needed, or keep it open for the enhancements!

Thanks for taking the time to test and share these details, that’s very helpful.

Agreed that this looks more like an enhancement than a strict timeout bug, especially given the behaviour of different endpoints and the underlying Dart HTTP client.

The primary goal from my side is to give users explicit control when they want to enforce limits, improve UX for very long-running requests, and handle rare stalled connections, rather than changing existing default behaviour.

As suggested by @animator, I’ll start by adding a configurable default timeout in Settings, keeping the scope limited to that first step. Per-request overrides and other enhancements can be layered on later if needed.

Thanks again for the insights.

[hannah-mnq]

This PR focuses only on introducing a safe, configurable default request timeout at the networking layer, as suggested.

I intentionally kept the change minimal and non-breaking. Advanced/per-request timeout controls and UI-level configuration will be added in a follow-up PR once this baseline is agreed upon.

@animator Please let me know if you’d prefer a different default value or any adjustments to the approach. Happy to iterate!