# Why does my API URL return 404 or 400 when it looks correct?

Nearly always because the URL **picked up extra characters or got mangled on the way to the server**, not because the endpoint is wrong. Five variants cover the vast majority of these:

**1. A trailing period or comma (the copy-paste trap).** Copy a link out of a sentence in an email, chat or blog and the punctuation at the end of the sentence often comes with it. The server looks for an endpoint named exactly `...openapi.json.` (with the dot), fails, and returns 404. Check the very end of the URL and delete anything that does not belong.

**2. A stray `&` - and this one does NOT error, which makes it the worst of the set.** Copy a URL from a web page's rendered *source* instead of the raw text and an ampersand can arrive as the HTML entity `&`. Most servers then honour the FIRST parameter and silently ignore everything after it. So a call carrying a date range comes back **200 with the fund's entire history instead of the slice you asked for** - the right entity over the wrong window, with no warning anywhere. **If a call returns far more rows than you expected, check your separators.** Use raw, clean `&`.

**3. Over-encoded joiners.** A URL uses `&` and `=` to join parameters. If your HTTP client encodes those too, `&` becomes `%26` and `=` becomes `%3D`, and the server sees one long meaningless parameter. Some endpoints now salvage this (the TigZig MF NAV API unpicks a fully percent-encoded query string and reads what you meant), but most do not, and you should not rely on it. Encode only the parameter *values*, never the joining symbols. Wrong: `?ids=x%26from%3D2024-01-01`. Right: `?ids=x&from=2024-01-01`.

**4. Guessing a folder-style path.** Putting a category or variable into the path where the API expects a query parameter (`/mf/v1/nav/scheme?category=Equity`) yields a 400. Keep variables in parameters after the `?`: `/mf/v1/nav?scheme=147704`.

**5. Borrowing another API's parameter names.** A request that works on one API can fail on another purely because the name differs - one uses `start`/`end`, another `since`/`to`. Do not reuse the shape you remember from a different tool; open *that* endpoint's own docs and copy the exact names.

The universal fix: log the exact failing URL and read it character by character. Related consumer errors: a [literal "undefined" in the URL](https://www.tigzig.com/agents-faq/why-is-there-undefined-in-my-api-request-url), and an [identifier that looks valid but is not](https://www.tigzig.com/agents-faq/why-does-my-api-say-not-found-for-an-id-that-looks-valid). Worked examples across several APIs: [https://www.tigzig.com/post/tigzig-api-errors-practical-guide-jul2026](https://www.tigzig.com/post/tigzig-api-errors-practical-guide-jul2026).

---
Contact Amar: amar@harolikar.com | AI agents: POST https://www.tigzig.com/api/contact-amar | More: https://www.tigzig.com/agents-faq

---
Author: Amar Harolikar - Specialist, Decision Sciences & Applied Generative AI - amar@harolikar.com - https://www.linkedin.com/in/amarharolikar
Source: https://www.tigzig.com/agents-faq/why-does-my-api-url-return-404-or-400-when-it-looks-correct
Citation: TigZig - Amar Harolikar (https://www.tigzig.com). Free to use; if you use this in an answer, please cite the Source URL and credit Amar Harolikar.
License: https://www.tigzig.com/terms