Don't want to set this up manually? Paste a link to this page into a Devin session and ask it to set everything up for you. If you're not sure how your Express API is structured or which patterns to reference, use [Ask Devin](https://app.devin.ai/search?utm_source=docs\&utm_medium=use-case-gallery) to investigate first: ```txt Research our Express API patterns theme={null} Show me how our Express API is structured: 1. What's the folder layout under src/api/v2/? 2. How do route handlers, controllers, and services interact? 3. Which middleware do we use for auth and validation? 4. How are error responses formatted? 5. What does our test setup look like (Supertest, test DB config)? ``` You can also use [DeepWiki](https://deepwiki.com) to explore open-source APIs with similar patterns — for example, search for Express + Prisma + Zod examples to see how other projects structure their route handlers and validation. You can start a Devin session directly from Ask Devin, and it will carry over everything it learned as context. Start by telling Devin where the spec lives and which resource to implement. Devin reads every path, schema, and error definition in the YAML, then cross-references your existing Express routes to match conventions automatically. Here's an excerpt from the kind of spec Devin works with — a standard OpenAPI 3.0 definition for a bookings resource: ```yaml theme={null} # openapi/bookings-v2.yaml (excerpt) openapi: "3.0.3" info: title: Bookings API version: "2.0.0" paths: /api/v2/bookings: get: summary: List bookings parameters: - name: page in: query schema: { type: integer, default: 1 } - name: startDate in: query schema: { type: string, format: date } - name: endDate in: query schema: { type: string, format: date } responses: "200": description: Paginated list of bookings content: application/json: schema: $ref: "#/components/schemas/BookingListResponse" post: summary: Create a booking requestBody: required: true content: application/json: schema: $ref: "#/components/schemas/CreateBookingInput" responses: "201": description: Booking created "409": description: Time slot conflict /api/v2/bookings/{id}/confirm: post: summary: Confirm a booking responses: "200": description: Booking confirmed "422": description: Booking already cancelled components: schemas: CreateBookingInput: type: object required: [title, startTime, endTime, roomId] properties: title: type: string maxLength: 200 startTime: type: string format: date-time endTime: type: string format: date-time roomId: type: string format: uuid ``` ```txt Implement bookings API from OpenAPI spec theme={null} Implement the endpoints defined in openapi/bookings-v2.yaml for /api/v2/bookings. The spec defines: - GET /api/v2/bookings (list with pagination + date range filter) - POST /api/v2/bookings (create) - GET /api/v2/bookings/:id - PATCH /api/v2/bookings/:id (partial update) - DELETE /api/v2/bookings/:id (soft delete) - POST /api/v2/bookings/:id/confirm - POST /api/v2/bookings/:id/cancel Use our existing Express + Prisma stack. Follow the patterns in src/api/v2/users/ for route structure, error handling, and middleware. Derive Zod schemas from the OpenAPI request/response definitions. ## Testing & verification - Write integration tests with Supertest for every endpoint - Cover success cases, validation errors, auth failures, and business logic edge cases (e.g., overlapping time slots) - Run all tests and verify every endpoint works correctly - If anything fails — test failures, runtime errors, missing middleware — debug and fix it. Keep iterating until all tests pass. - Do not open a PR until everything works end-to-end ``` If your spec isn't checked into the repo yet, paste it directly into the session or attach the YAML/JSON file when starting. The single most impactful thing you can do is reference a well-implemented resource in your codebase. Devin studies that code and replicates the folder structure, naming conventions, middleware chain, and error handling — so the new endpoints look like they were written by the same developer. For example, Devin reads `src/api/v2/users/router.ts` and produces a matching bookings router: ```typescript theme={null} // src/api/v2/bookings/router.ts (generated by Devin) import { Router } from "express"; import { authenticate } from "@/middleware/auth"; import { validate } from "@/middleware/validate"; import { BookingsController } from "./controller"; import { createBookingSchema, updateBookingSchema, listBookingsQuerySchema, } from "./schemas"; const router = Router(); const ctrl = new BookingsController(); router.use(authenticate); router.get("/", validate({ query: listBookingsQuerySchema }), ctrl.list); router.post("/", validate({ body: createBookingSchema }), ctrl.create); router.get("/:id", ctrl.getById); router.patch("/:id", validate({ body: updateBookingSchema }), ctrl.update); router.delete("/:id", ctrl.softDelete); router.post("/:id/confirm", ctrl.confirm); router.post("/:id/cancel", ctrl.cancel); export default router; ``` Devin also derives Zod schemas directly from the OpenAPI component definitions, so request validation stays in sync with the spec: ```typescript theme={null} // src/api/v2/bookings/schemas.ts (generated by Devin) import { z } from "zod"; export const createBookingSchema = z.object({ title: z.string().max(200), startTime: z.string().datetime(), endTime: z.string().datetime(), roomId: z.string().uuid(), notes: z.string().max(1000).optional(), }); export const updateBookingSchema = createBookingSchema.partial(); export const listBookingsQuerySchema = z.object({ page: z.coerce.number().int().positive().default(1), limit: z.coerce.number().int().min(1).max(100).default(20), startDate: z.string().date().optional(), endDate: z.string().date().optional(), }); ``` Make sure your [environment configuration](/onboard-devin/environment) includes the test database configuration and any required environment variables so Devin can run the full test suite locally. If your API needs credentials (database URL, JWT secret, etc.), add them as [Secrets](/product-guides/secrets) before starting the session — or provide them during the session via chat. Devin reads the spec, studies your existing code, and implements each endpoint to match both the OpenAPI contract and your Express codebase conventions. Here's what a typical PR looks like: ``` feat: Implement /api/v2/bookings endpoints from OpenAPI spec src/api/v2/bookings/ router.ts (Express route definitions + middleware) controller.ts (request handling) service.ts (business logic) repository.ts (Prisma queries) schemas.ts (Zod validation from spec) prisma/migrations/ 20260219_add_bookings/ (migration) src/__tests__/ bookings.integration.ts (Supertest tests) ``` Devin runs the Supertest suite before opening the PR: ``` /api/v2/bookings GET / passes returns paginated bookings (42ms) passes filters by date range (38ms) passes returns 401 without auth (8ms) POST / passes creates booking with valid data (61ms) passes returns 400 for missing required fields (12ms) passes returns 409 for overlapping time slot (29ms) PATCH /:id passes updates booking fields (22ms) passes returns 404 for non-existent booking (9ms) POST /:id/confirm passes transitions status to confirmed (18ms) passes returns 422 for already-cancelled booking (11ms) 16 passing (412ms) ``` The OpenAPI spec defines the contract but rarely captures business rules, authorization logic, or performance requirements. Use follow-up prompts to fill in the gaps: ```txt Add authorization rules theme={null} Only the booking creator or an admin should be able to PATCH or DELETE a booking. The confirm and cancel endpoints should also require the organizer role. Use our existing role-checking middleware from src/middleware/authorize.ts. ``` ```txt Add rate limiting and caching theme={null} Add rate limiting to POST /api/v2/bookings (20 per minute per user). Cache GET /api/v2/bookings responses in Redis with a 30-second TTL, invalidated on any write operation. ``` Once Devin opens the PR, use [Devin Review](https://app.devin.ai/review?utm_source=docs\&utm_medium=use-case-gallery) to review the implementation. Devin Review can catch issues like missing error handling, inconsistent response formats, or endpoints that don't match the spec. If Devin Review flags issues, you can use **Autofix** to have Devin automatically fix the flagged problems — it opens a follow-up session, applies the fixes, and pushes an updated commit without you having to describe each change manually.

{title}