Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/fredy-rizo/despacho-backend/llms.txt

Use this file to discover all available pages before exploring further.

Despacho Backend centralises all runtime configuration in a single .env file at the project root. At startup, src/config.js calls dotenv.config() which reads the file, populates process.env, and then exports the three variables — PORT, SECRET, and MONGODB_URL — as a plain object that every module in the application imports. If a variable is missing or the file does not exist, the exported value falls back to an empty string, which will cause runtime failures, so all three must be set before starting the server.

Environment variables

PORT
number
default:"3000"
The TCP port on which the Express HTTP server listens for incoming connections. src/index.js reads this value as config.PORT || 3000, so omitting it from .env is safe in development — the server will bind to port 3000. In production, set it explicitly to match your reverse proxy or hosting platform’s expected port (e.g. 8080 on many PaaS providers).
SECRET
string
required
The secret string used to sign JWTs when a lawyer logs in and to verify them on every subsequent authenticated request. jsonwebtoken uses this value with the HS256 algorithm. There is no default — if SECRET is an empty string, jwt.sign() will produce tokens that are trivially forgeable by anyone who knows the value. This variable is required and must be a long, random, high-entropy string. See the JWT secret best practices section below.
MONGODB_URL
string
required
The full MongoDB connection URI passed directly to mongoose.connect(). The database name is included in the URI path segment (e.g. /despacho). Both local mongod instances and MongoDB Atlas cluster URIs are supported. See the MongoDB setup section for examples of each format.

Example .env file

Copy this template to the project root and fill in your own values:
# .env  —  never commit this file to source control

# HTTP server port
PORT=3000

# JWT signing secret — replace with a long random string
SECRET=a8f3d2c1e9b04f7a6d5c2e8b1a4f9e3d2c7b0a5f1e6d3c8b2a9f4e7d1c5b0a3

# MongoDB connection URI
MONGODB_URL=mongodb://localhost:27017/despacho

MongoDB setup

Local MongoDB instance

If you have MongoDB installed locally and mongod is running on the default port, use:
MONGODB_URL=mongodb://localhost:27017/despacho
Mongoose will create the despacho database automatically on the first write. You can verify connectivity by checking for the Connected to Mongoose ✅ log line at startup. If your local instance requires authentication, include the credentials in the URI:
MONGODB_URL=mongodb://myUser:myPassword@localhost:27017/despacho?authSource=admin

MongoDB Atlas

For a cloud-hosted Atlas cluster, retrieve the connection string from the Atlas UI (Database → Connect → Drivers) and paste it as MONGODB_URL:
MONGODB_URL=mongodb+srv://myUser:myPassword@cluster0.abcde.mongodb.net/despacho?retryWrites=true&w=majority
Make sure:
  1. Your current IP address is added to the Atlas Network Access allowlist (or use 0.0.0.0/0 for development).
  2. The database user has read and write permissions on the despacho database.
  3. The URI includes the database name (/despacho) so Mongoose targets the correct database.

JWT secret best practices

The SECRET variable is the single most sensitive piece of configuration in Despacho Backend. Tokens are signed with HS256 — a symmetric algorithm — meaning the same secret is used to both create and verify tokens. Anyone who possesses SECRET can forge a valid JWT and gain unrestricted access to all lawyer-only endpoints.
A weak or leaked SECRET completely undermines the authentication system. An attacker who obtains it can craft a token for any _id, log in as any lawyer, list all client reservations, accept or delete them, and there is no cryptographic way to detect the forgery. Rotate SECRET immediately if you suspect it has been exposed — all existing tokens will be invalidated and lawyers will need to log in again.
Follow these practices:
  • Use at least 32 bytes of randomness — that is 64 hex characters or 43 base64 characters. Shorter secrets are vulnerable to brute-force attacks against the HS256 signature.
  • Generate it with a cryptographically secure source. A convenient one-liner using Node.js’s built-in crypto module:
Run this command to generate a production-strength secret and paste the output directly into your .env:
node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"
Example output: a8f3d2c1e9b04f7a6d5c2e8b1a4f9e3d2c7b0a5f1e6d3c8b2a9f4e7d1c5b0a3
  • Never hard-code it in config.js or any source file. Always read it from the environment.
  • Never commit .env to Git. Add .env to .gitignore before your first commit:
    echo ".env" >> .gitignore
    
  • Use different secrets per environment. Your local development secret, staging secret, and production secret should all be distinct so a leak in one environment does not affect others.
  • Rotate on suspicion. Because tokens have a 365-day expiry, rotating SECRET is the only way to invalidate all outstanding tokens if a breach is suspected.

Build docs developers (and LLMs) love