Replit Agent prompt to build a REST API
This spec gives Replit Agent everything an API build needs decided up front: routes, pagination rules, an error envelope, and a health check. The agent scaffolds the project, attaches a database, seeds it, and curls each endpoint from the shell, leaving you a deployable service instead of a stub.
Last updated
Build a REST API in {{language}} on Replit, backed by {{database}}, for managing {{resource}}.
Endpoints:
- GET /api/{{resource}}: paginated list. Query params limit (default 20, max 100) and offset. Response includes items and total.
- GET /api/{{resource}}/:id
- POST /api/{{resource}}: validate the body, reject unknown fields with a 400 listing them.
- PATCH /api/{{resource}}/:id: partial update. An empty body is a 400.
- DELETE /api/{{resource}}/:id: returns 204, then 404 on repeat.
- GET /healthz: 200 plus a live database connectivity check.
Data model: id, created_at, updated_at, and the fields a {{resource}} record realistically needs. Propose the schema in chat before writing code so I can correct field names cheaply.
Error contract: every failure returns JSON shaped { "error": { "code", "message", "fields" } }. Validation failures are 400 with per-field messages. A malformed id is 400, not 500. Nothing ever leaks a stack trace to the client. Unsupported methods on known routes return 405.
Setup: read the database URL from an environment variable via Replit Secrets, never hardcode it. Add request logging middleware. Write a seed script that inserts 25 varied rows and is safe to re-run.
Verify before you stop: start the server, curl every endpoint from the shell including the failure cases above, and paste each status code with one sample body into chat. Then configure the Repl for deployment and tell me which deployment type you chose and why.Customize it
Runs in your browser. Nothing you type here is sent anywhere.
Build a REST API in TypeScript on Replit, backed by PostgreSQL, for managing users.
Endpoints:
- GET /api/users: paginated list. Query params limit (default 20, max 100) and offset. Response includes items and total.
- GET /api/users/:id
- POST /api/users: validate the body, reject unknown fields with a 400 listing them.
- PATCH /api/users/:id: partial update. An empty body is a 400.
- DELETE /api/users/:id: returns 204, then 404 on repeat.
- GET /healthz: 200 plus a live database connectivity check.
Data model: id, created_at, updated_at, and the fields a users record realistically needs. Propose the schema in chat before writing code so I can correct field names cheaply.
Error contract: every failure returns JSON shaped { "error": { "code", "message", "fields" } }. Validation failures are 400 with per-field messages. A malformed id is 400, not 500. Nothing ever leaks a stack trace to the client. Unsupported methods on known routes return 405.
Setup: read the database URL from an environment variable via Replit Secrets, never hardcode it. Add request logging middleware. Write a seed script that inserts 25 varied rows and is safe to re-run.
Verify before you stop: start the server, curl every endpoint from the shell including the failure cases above, and paste each status code with one sample body into chat. Then configure the Repl for deployment and tell me which deployment type you chose and why.Same task in other tools
Questions about this prompt
Does Replit Agent set up the database itself or do I have to?
It can attach Replit's built-in PostgreSQL and read the connection string from an environment variable, which is the smoothest path. If your spec names an external database instead, create it first, add its URL through the Secrets pane, and tell the agent the variable name.
The agent said it finished but never ran the curl checks. What now?
Reply with the verification block on its own: start the server, curl every endpoint including the failure cases, paste status codes. It has a shell, so it can comply, and if a fix breaks a passing route you can roll back to the previous checkpoint.
How do I control the fields on the resource without rewriting the prompt?
The prompt makes the agent propose the schema in chat before coding. Correct field names and types at that step; it is far cheaper than migrating after the seed script has populated rows and queries reference the old columns.