Dynamic API routes return 404 on Vercel but not locally (Next 14.0.1, app router)

Answered

Ben Greene posted this in #help-forum

Open in Discord

2023-11-15T14:41:33.000Z

Hi all - I have a very annoying error that I can't seem to fix. This is on Next 14.0.1 using app router.

The specific behavior is that certain API routes are returning 404 errors instead of loading, but only when deployed to Vercel. The attached image shows the directory structure of the API routes - the specific routes that fail are api/programs/[id] and api/programs/page/[page]. The api/users, api/users/[id], and api/programs routes all return results.

There does not appear to be any significant difference in the route.ts files. Does anyone have suggestions on what I could try?

Thank you ðŸ™

Answered by Ben Greene

Update: although the why still eludes us, we were able to resolve the problem. The cause seems to be having a directory in the root of the project (at the same level as app) called api. This was being used for some library files. Renaming that directory from api to apiServices seems to be the only change required to make the dynamic routes begin functioning properly again.

View full answer

116 Replies

Siricid woodwasp

2023-11-15T14:46:34.000Z

where are you calling those apis in client or server?

2023-11-15T14:59:17.000Z

@Siricid woodwasp Sorry, I'm not completely sure I understand your question. Whether I make the API call from within a component or directly via the web browser, I get the 404 either way.

Siricid woodwasp

2023-11-15T15:01:50.000Z

i mean how are you calling api end points in your app like fetch("api/user")

2023-11-15T15:03:33.000Z

Ahh - const response = await get(programs/page/${page});

Siricid woodwasp

2023-11-15T15:03:47.000Z

are those client components?

2023-11-15T15:04:19.000Z

It's a lib used within client components, I believe - will need to check, currenly away from desk

2023-11-15T16:08:16.000Z

confimed, client components

but I'm fairly sure that the problem is somehow elsewhere, because accessing the API call directly from the browser also fails ðŸ˜•

2023-11-15T17:50:19.000Z

@Siricid woodwasp I think I've made some progress - this seems to only hit API calls that have a dynamic element in them, e.g. programs/page/[page] - it turns out that users/[id] doesn't work either (on Vercel - still works fine locally).

Northern snakehead

2023-11-15T18:08:29.000Z

just going to jump in here and follow this as I believe i have the same issue ðŸ™‚

2023-11-15T18:14:48.000Z

I updated the title to be a bit more specific and hopefully garner more assistance ðŸ™

2023-11-15T18:23:31.000Z

Yo Folks. Let's solve this - at the beginning @Ben Greene, could you provide us with this endpoint code/repository url (if it's public) or minimal reproduction?

https://nextjs-faq.com/minimal-reproduction-repository

also if that's possible please share an screenshot of that 404 error which you get - this will help assign if we have problem with vercel (platform) or nextjs (your code)

2023-11-15T18:52:08.000Z

@Z4NR34L appreciate your help!
Here's a screenshot of the 404 on Vercel (left) and the 200 on localhost (right):

The repo is not public, so it'll take me some time to create a new test repo

While I get that ready - my colleague believes that not having NEXT_PUBLIC_API_URL defined in the ENV variables may be a cause of this problem - could that be the case? And if so, how is one supposed to generate that in Vercel preview deployments?

2023-11-15T19:22:49.000Z

Ok, There is no chance to get into the cause of this issue without even minimal reproduction or code, we can just guess, and env variables is the first thing that should be double checked before deployment ðŸ˜„

scan your code which env vars are you using, remember that if you use variable in route handler you dont need to add NEXT_PUBLIC_ prefix as itâ€™s executed server-side

2023-11-15T19:26:45.000Z

lol yeah, I'm working on a repro now

2023-11-15T19:27:18.000Z

if you don't have any hardcoded credentials, just post endpoint code here, that should be fine for now

2023-11-15T19:28:46.000Z

Sure, so here is the contents of app/api/programs/page/[page]/route.ts:

import { PrismaClient } from '@prisma/client';
import { NextRequest, NextResponse } from "next/server";

const prisma = new PrismaClient();

export async function GET(request: NextRequest) {
  const prisma = new PrismaClient();
  const programs = await prisma.program.findMany();
  return NextResponse.json(programs);
}

2023-11-15T19:29:05.000Z

also check your env vars on vercel, if you have selected all needed environments (Development/Preview/Production)

2023-11-15T19:29:39.000Z

And that exact same code works in app/api/programs/route.ts

2023-11-15T19:30:09.000Z

huh, I see

are you running prisma generate during the build step? ðŸ˜„

2023-11-15T19:31:20.000Z

2023-11-15T19:31:33.000Z

ok, did you checked env vars?

you need preview + production on vercerl to get it work there

2023-11-15T19:32:30.000Z

Well I don't have DATABASE_URL at all, but the above returns data from the DB on the non-dynamic route

I have POSTGRES_URL

2023-11-15T19:32:58.000Z

ok, I meant any env vars that are used there

@Ben Greene Sure, so here is the contents of `app/api/programs/page/[page]/route.ts`: import { PrismaClient } from '@prisma/client'; import { NextRequest, NextResponse } from "next/server"; const prisma = new PrismaClient(); export async function GET(request: NextRequest) { const prisma = new PrismaClient(); const programs = await prisma.program.findMany(); return NextResponse.json(programs); }

2023-11-15T19:35:19.000Z

first, let's try to check if everything is just building fine, replace this code with:

import { NextRequest, NextResponse } from "next/server";

export async function GET(request: NextRequest, {params}: { params: { page: number }}) {
  return NextResponse.json({page: params.page});
}

and verify if you get back number you provided in path

2023-11-15T19:36:39.000Z

pushed to vercel

still a 404

I'm not an expert on Next.js by any means, but I don't think the code content of the route itself is playing much of a role

2023-11-15T19:41:58.000Z

that's what we needed to verify

Now, please share your next.config and middleware (if any), also vercel.json if used

and to be sure, post file path in repository, and URL without domain

2023-11-15T19:44:07.000Z

next.config.js:

/** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true,
  swcMinify: true,
  images: {
    domains: ["lh3.googleusercontent.com", "vercel.com"],
  },
  async redirects() {
    return [
      {
        source: "/github",
        destination: "https://github.com/steven-tey/precedent",
        permanent: false,
      },
    ];
  },
};

module.exports = nextConfig;

(I should probably change that github source from the repo I cloned)

middleware.ts:

import createMiddleware from 'next-intl/middleware';
import { LOCALES } from '@/lib/constants';
 
export default createMiddleware({
  // A list of all locales that are supported
  locales: LOCALES,
 
  // If this locale is matched, pathnames work without a prefix (e.g. `/about`)
  defaultLocale: 'en'
});
 
export const config = {
  // Skip all paths that should not be internationalized. This example skips the
  // folders "api", "_next" and all files with an extension (e.g. favicon.ico)
  matcher: ['/((?!api|_next|.*\\..*).*)']
};

No vercel.json

2023-11-15T19:48:01.000Z

ok, so url without domain and file path in repository - just for double-check

also please check your vercel logs if there is no errors ðŸ˜‰

2023-11-15T19:49:34.000Z

the relative file path (copied from VS Code) is: app/api/programs/page/[page]/route.ts

And the URL without domain: /api/programs/page/1

the deployment logs say 0 errors and 0 warnings

I've read through it and not seen anything particularly interesting

although it does identify the routes in question:

Route (app)                              Size     First Load JS
â”Œ â—‹ /_not-found                          882 B          89.2 kB
â”œ Î» /[locale]                            559 B           124 kB
â”œ Î» /[locale]/about                      550 B           124 kB
â”œ Î» /[locale]/auth/error                 957 B           124 kB
â”œ Î» /[locale]/auth/signin                863 B           135 kB
â”œ Î» /[locale]/auth/verify-request        1 kB            124 kB
â”œ Î» /[locale]/programs                   2.24 kB         125 kB
â”œ Î» /[locale]/programs/[id]              2.4 kB          125 kB
â”œ Î» /[locale]/programs/edit/[id]         1.11 kB         227 kB
â”œ Î» /[locale]/programs/new               572 B           227 kB
â”œ Î» /[locale]/users/[id]/edit            1.59 kB         125 kB
â”œ Î» /api/auth/[...nextauth]              0 B                0 B
â”œ Î» /api/programs                        0 B                0 B
â”œ Î» /api/programs/details/[id]           0 B                0 B
â”œ Î» /api/programs/page/[page]            0 B                0 B
â”œ â—‹ /api/users                           0 B                0 B
â”” Î» /api/users/[id]                      0 B                0 B
+ First Load JS shared by all            88.3 kB
  â”œ chunks/472-e4fe7de096be0269.js       33 kB
  â”œ chunks/fd9d1056-1de2bf583fdbc1a8.js  53.2 kB
  â”œ chunks/main-app-892c3dff08e9cd4c.js  232 B
  â”” chunks/webpack-fbec2224bf4eac50.js   1.87 kB

2023-11-15T19:53:07.000Z

huh

2023-11-15T19:53:39.000Z

sounds like we're on the same page

2023-11-15T19:54:16.000Z

wait a sec

I'm using dynamic route handlers in my projects but I see that there is small difference

I'm on edge runtime

try to change our test route to edge ðŸ˜„

export const runtime = 'edge'

2023-11-15T19:55:59.000Z

It's off ðŸ¿

ðŸ‘Ž ðŸ˜ž

2023-11-15T19:57:54.000Z

you are using next-auth

you are not locking those urls? ðŸ˜„

2023-11-15T19:58:29.000Z

...?

2023-11-15T19:59:07.000Z

maybe I will ask in other words: are you using next-auth to auth users before accessing those routes?

I mean api routes

2023-11-15T19:59:38.000Z

oh - no, I'm not - though I certainly will down the line

2023-11-15T20:00:26.000Z

the problem is - I cannot reproduce that issue in clean next.js - so maybe one of packages that you had used is messing around

but let's try one more thing - remove middleware for now

just to get as clean access to route as possible

2023-11-15T20:02:55.000Z

What version of nextjs are you on

2023-11-15T20:02:57.000Z

do you see any errors from the logs on vercel dashboard?

2023-11-15T20:04:39.000Z

not really:

though I didn't expect a 204...

2023-11-15T20:06:07.000Z

I'm using 14.0.2 currently

you are viewing a HEAD method request log, and you are supposed to make an GET method

2023-11-15T20:08:06.000Z

yeah.... weird

2023-11-15T20:08:41.000Z

but /api/programs is working fine from what I can see

2023-11-15T20:08:49.000Z

correct

2023-11-15T20:09:03.000Z

but, can you see more logs on vercel now?

2023-11-15T20:11:17.000Z

this is so bizarre

here's chrome inspector:

but there's no corresponding 404 in vercel:

I'm on 14.0.1, so I'm gonna upgrade that just to see

2023-11-15T20:12:21.000Z

there is still middleware that's working

try disabling/removing it for now

2023-11-15T20:12:58.000Z

sorry that middleware is from a different branch

2023-11-15T20:13:04.000Z

ok

I remember that I was not using next-intl for a reason with appdir ðŸ˜„ But not sure what exacly problem that was

2023-11-15T20:13:46.000Z

::blinks::

2023-11-15T20:13:48.000Z

I've made my own middlware for locales routing

/api/users/[id] is not working too from what I checked now

2023-11-15T20:14:50.000Z

correct

no dynamic api route is

I wonder if it worked when I started this with 13.5......

2023-11-15T20:15:46.000Z

hmm, that's pretty wide problem, and I think I'm not able to help you without testing this right on your repository :/

2023-11-15T20:16:24.000Z

i can't reproduce it too

14.0.1 also work for me
https://test-page-kappa.vercel.app/api/programs/page/2

2023-11-15T20:22:24.000Z

Interesting.
Also interesting: after upgrading to 14.0.2, I now get this error:

app/api/auth/[...nextauth]/route.ts
Type error: Route "app/api/auth/[...nextauth]/route.ts" does not match the required types of a Next.js Route.
  "authOptions" is not a valid Route export field.

2023-11-15T20:27:49.000Z

^^^ this is not so much interesting as just annoying

2023-11-15T20:28:51.000Z

what version of next-auth are you using

2023-11-15T20:29:30.000Z

4.22.1

2023-11-15T20:30:38.000Z

does the api work if you change the middleware file to _middleware

2023-11-15T20:34:34.000Z

sorry had to get back to a working state - so just rename it to _middleware...

2023-11-15T20:42:04.000Z

I mean the short answer is that obviously kills my locale-enabled pages... working on actually getting a successful deploy through Vercel... been making a lot of changes quickly...

Ok! Results are in, and removing/renaming middleware file does not make the dynamic API routes functional.

2023-11-15T21:29:19.000Z

So that case too wide to debug it just by telling you what to do, badly. Easiest way would be making a reproduction or allowing us to view the origin code

2023-11-15T23:55:25.000Z

@Z4NR34L I DMed you

2023-11-16T07:45:09.000Z

Update: This topic is in progress - if we find a solution, I'll post it there

2023-11-16T14:15:34.000Z

Update: although the why still eludes us, we were able to resolve the problem. The cause seems to be having a directory in the root of the project (at the same level as app) called api. This was being used for some library files. Renaming that directory from api to apiServices seems to be the only change required to make the dynamic routes begin functioning properly again.

Answer

2023-11-16T14:16:31.000Z

brilliant ðŸ˜„

2023-11-16T14:16:57.000Z

Right?! ðŸ˜ž

2023-11-16T14:17:52.000Z

that's perfect example why it's important for others to see whole code/repository or reproduction ðŸ˜„

Berger Picard

2023-11-17T00:26:42.000Z

hey sorry to revive this, I'm having the exact same issue but with localhost

/api/players returns 404

even in postman

its really bare too

@Berger Picard /api/players returns 404

2023-11-17T00:31:00.000Z

why are you not using route.ts as players.ts is going to be ignored.... also for future can you make a new thread as everyones are diferent

Berger Picard

2023-11-17T00:32:17.000Z

why

2023-11-17T00:34:03.000Z

what do you mean by "why"?

your /api isn't going to be usable, idk if thats intentional