masonite api

[ssestantech]

Describe the bug

i am using masonite api . its working perfect on localhost. but when i go to production then its showing
api routes not found 404.

Expected behaviour

i am using masonite api . its working perfect on localhost. but when i go to production then its showing
api routes not found 404.

Steps to reproduce the bug

No response

Screenshots

No response

OS

Linux

OS version

Linux

Browser

No response

Masonite Version

4.6.1

Anything else ?

No response

[girardinsamuel]

Can you test if your routes are correctly displayed in production with the python craft routes:list command ? It should display a list of the configured routes for the current environement. If it is displayed there then maybe it's not an issue with Masonite itself ?

Are you using a proxy like Nginx ?

[ssestantech]

masonite.exceptions.exceptions.MissingContainerBindingNotFound: routes.api.location key was not found in the container

[ssestantech]

[ssestantech]

but api/users give 404

[ssestantech]

masonite api not working on subdomain

[ssestantech]

any solution

[circulon]

@ssestantech

masonite.exceptions.exceptions.MissingContainerBindingNotFound: routes.api.location key was not found in the container

As per the error shown in your screenshot the routes.api.location binding is missing.
As per the documentstion: https://docs.masoniteproject.com/features/api
You will then have to add a binding to the container for the location of this file. You can do so in your Kernel.py file inside the register_routes method:

Additionally check your APP_URL in config.application on your production system as this needs to be the full base endpoint as I understand it ie https://sub.domain.acme.com

Personally I found this quite limiting when it comes to deploying to multiple environments (ie local, dev, staging, prod) as I had to manually modify each env config for specific usage.
This is entirely due to visibility of env vars available to AWS Lambda.
So I extended the config mechanism to be fully inherited config stack that could be tracked in version control and built dynamically accoring to the deployed env requirements.
But thats just how I decided to do it for repeatability and ease of deployment