The error shows that I used user_id but the business_accounts table has owner_user_id instead. Let me fix the advertisements router:

Now let me check if there are other occurrences of this same issue in the advertisements router:

I also need to verify the BusinessAccount model in models.py has the correct field name:

The model already has owner_user_id, and I've fixed the query in the advertisements router. The fix changes BusinessAccount.user_id to BusinessAccount.owner_user_id to match the actual database column name. Try submitting the advertisement again now.

The frontend calls GET /admin/listings but the backend doesn't have this route. Let me check what admin routes exist:

There IS a GET /listings at line 597. But the frontend is calling GET /admin/listings/details based on the error log. Let me check the frontend Listings.js more closely:

The backend has GET /admin/listings (line 597) and the frontend calls /admin/listings (line 37) which should match. But the error says GET /admin/listings/details - that's a different path. There might be a duplicate or conflicting route. Let me check all routes more carefully:

Interesting - there's no listings/details in the code at all. The log shows GET /admin/listings/details?page=1&limit=20. This is likely a route conflict - the request to GET /admin/listings is being matched by a different route that only accepts PUT/POST/DELETE, causing 405. Let me check for duplicate/conflicting routes:

I see the problem. There are duplicate routes in admin.py. The PUT /listings/{listing_id}/feature exists at both line 184 AND line 709, and PUT /listings/{listing_id}/rank exists at both line 203 AND line 728. Also the GET /listings at line 597 has route conflict with PUT /listings/{listing_id} routes defined earlier. The {listing_id} path parameter routes (like /listings/details being matched as /listings/{listing_id} where listing_id=details) could cause a 405 because details is matched as listing_id but only PUT/DELETE are defined for those paths.

Actually wait - the error says the path is /admin/listings/details. The word "details" is being matched by {listing_id} in the PUT routes. Since there's no GET route for /listings/{listing_id}, it returns 405.

But the frontend calls /admin/listings?page=1&limit=20, not /admin/listings/details. Let me check if there's something intercepting or redirecting:

The frontend calls /admin/listings?${params} correctly but the log shows /admin/listings/details. Let me check the api.js base URL and interceptors:

The frontend code at line 37 looks correct: /admin/listings?${params}. But the error log says /admin/listings/details. This is very strange. Let me look at the listings router (not admin router) - there might be a separate /listings router with prefix that's conflicting:

OK, the listings router has prefix /listings, admin router has prefix /admin. So the problem might be a route ordering issue in FastAPI where /admin/listings is being incorrectly matched. But the log clearly says /admin/listings/details which is NOT what the frontend sends.

The real issue is likely that GET /admin/listings with page=1&limit=20 is being matched to PUT /admin/listings/{listing_id} path routes (where listing_id catches any path segment). But actually, FastAPI should handle this correctly since the methods are different (GET vs PUT).

Let me look at the route ordering more carefully. The GET /admin/listings at line 597 comes AFTER the PUT /listings/{listing_id}/feature at line 184. In FastAPI, route ordering matters - if GET /listings/{listing_id} doesn't exist but there are only PUT routes at /listings/{listing_id}/*, then GET /listings should still match correctly.

Wait - the error says GET /admin/listings/details not GET /admin/listings. This means the frontend IS sending a request to /admin/listings/details. Let me search more broadly:

The frontend doesn't have listings/details anywhere. The URL /admin/listings/details in the log is FastAPI matching listings as the path and details being matched as {listing_id} by one of the PUT routes. When GET is used, it returns 405 because only PUT is allowed on that path pattern.

The real problem is route ordering. The GET /admin/listings (line 597) is defined AFTER the {listing_id} routes (lines 184, 203, 223, 250). FastAPI checks routes in order, so GET /admin/listings could be caught by a path-parameter route first. But since GET method doesn't match PUT, FastAPI is returning 405.

The fix is to move the GET /admin/listings route BEFORE the {listing_id} routes. Let me also remove the duplicate routes:

Now let me see the first set of listing routes (lines 183-265) and the second set (lines 663+) so I can understand the duplicates:

Now I see the full picture. The route ordering problem is: 1. Line 184: `PUT /listings/{listing_id}/feature` 2. Line 203: `PUT /listings/{listing_id}/rank` 3. Line 223: `DELETE /listings/{listing_id}` 4. Line 250: `PUT /listings/{listing_id}/archive` 5. ... 6. Line 597: `GET /listings` <-- This comes AFTER the `{listing_id}` routes When FastAPI sees `GET /admin/listings`, it first tries to match against the `{listing_id}` pattern routes (line 184 onwards). The path `/listings` can match `/listings/{listing_id}` where `listing_id = ""`... but that's not how it works. Actually, the real issue from the error log is `GET /admin/listings/details`. The word "details" in the URL is what's being caught by `{listing_id}` routes. This means the frontend IS sending `/admin/listings/details` somehow. But we don't see it in the code. Let me check if there was a previous version or if the browser is caching an old URL. Regardless, the fix should be to move `GET /listings` BEFORE the `{listing_id}` routes, and also remove the duplicates. Let me do a clean fix:

Now let me remove the duplicate GET /listings route that was defined later in the file:

Now let me remove the duplicate GET /listings block (lines 701-764) and also the duplicate GET /listings/ranked and GET /listings/pending and duplicate PUT feature/rank routes that are later in the file:

Now let me remove the duplicate PUT feature and PUT rank routes that come after the status route:

Now I'll remove the duplicate feature, rank, ranked, and pending routes (lines 747-821) since they're already defined earlier in the file:

The fix was a route ordering issue in FastAPI. The GET /admin/listings endpoint was defined after PUT /admin/listings/{listing_id}/... routes. FastAPI matches routes in order of definition, so a GET request to /admin/listings was being matched against the {listing_id} pattern routes first, and since those only have PUT/DELETE methods, it returned a 405 Method Not Allowed. I moved GET /listings, GET /listings/ranked, and GET /listings/pending before all the {listing_id} routes, and removed the duplicate route definitions that were scattered throughout the file.