Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.devin.ai/llms.txt

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

1

(Facultatif) Étudiez vos modèles d'API existants

Si vous ne savez pas comment votre API Express est structurée ni à quels patterns vous référer, utilisez Ask Devin pour commencer votre analyse :Vous pouvez aussi utiliser DeepWiki pour explorer des API open source présentant des patterns similaires — par exemple, recherchez des exemples Express + Prisma + Zod pour voir comment d’autres projets structurent leurs gestionnaires de routes et leur validation.Vous pouvez démarrer une session Devin directement depuis Ask Devin, et tout ce qu’il a appris sera conservé comme contexte.
2

Pointez Devin vers votre spécification OpenAPI

Commencez par indiquer à Devin où se trouve la spécification et quelle ressource implémenter. Devin lit chaque chemin, schéma et définition d’erreur dans le YAML, puis les compare à vos routes Express existantes afin d’aligner automatiquement les conventions.Voici un extrait du type de spécification que Devin utilise — une définition standard OpenAPI 3.0 pour une ressource de réservations :
# 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
If your spec isn’t checked into the repo yet, paste it directly into the session or attach the YAML/JSON file when starting.
3

Devin matches your Express patterns

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:
// 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:
// src/api/v2/bookings/schemas.ts  (généré par 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(),
});
Assurez-vous que la configuration de l’environnement inclut la configuration de la base de données de test et toutes les variables d’environnement nécessaires afin que Devin puisse exécuter l’ensemble de la suite de tests en local. Si votre API a besoin d’identifiants (URL de base de données, secret JWT, etc.), ajoutez-les en tant que Secrets avant de lancer la session — ou fournissez-les pendant la session via le chat.
4

Devin delivers a tested PR

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)
5

Approfondissez ce que la spécification ne couvre pas

La spécification OpenAPI définit le contrat mais capture rarement les règles métier, la logique d’autorisation ou les exigences de performance. Utilisez des prompts complémentaires pour combler ces lacunes :
6

Passez en revue la PR avec Devin Review

Une fois que Devin a ouvert la pull request (PR), utilisez Devin Review pour examiner l’implémentation. Devin Review peut détecter des problèmes comme l’absence de gestion des erreurs, des formats de réponse incohérents ou des endpoints qui ne respectent pas la spécification.Si Devin Review signale des problèmes, vous pouvez utiliser Autofix pour que Devin corrige automatiquement les problèmes signalés — il ouvre une session de suivi, applique les corrections et pousse un commit mis à jour sans que vous ayez à décrire chaque changement manuellement.