Build a FastAPI Backend With AI: REST API, Authentication and a Persistent Database

This guide builds the backend of an AI-assisted full-stack app step by step. It covers creating a FastAPI REST API with SQLite, adding authentication, connecting the React frontend and persisting board state across sessions with a proper database schema.

Building a FastAPI back-end with an AI copilot goes smoothly when you follow a clear, repeatable sequence instead of asking for the whole thing at once. This guide gives you that sequence: plan the API, scaffold the app, define models, add SQLite storage, then loop through endpoint, test and commit. It also shows how to add an AI chat endpoint that calls a language model while keeping the API key safe.

Why a step-by-step workflow beats one big generation

Asking the copilot for a whole back-end at once produces an unreviewable blob you cannot trust. Building one piece at a time keeps each change small enough to review and test, so problems surface immediately and the back-end stays sound as it grows.

The methodical approach is slower to start but far faster overall. It sits at the centre of good agentic building, where the workflow matters as much as the stack. Small steps, review and tests are what turn a fast agent’s speed into trustworthy progress rather than a pile of unreviewed code.

The stack: FastAPI, SQLite and a language model

Three pieces fit together cleanly. FastAPI defines the endpoints and handles requests. SQLite stores the data in a single file with no separate server to run. A call to a language model powers the chat feature.

Think of it as the API on top, the database beneath and the model called out to. It is a lightweight but capable combination, well suited to a solo or AI-assisted build, and each piece has a clear job. Understanding how the parts relate keeps the build organized from the first prompt.

Plan the API before generating code

Decide what the API does before the copilot writes anything. List the resources, the endpoints and the data each needs: what reads, what writes and what the chat does. That short plan gives the agent a clear target and gives you something to review against, rather than letting it invent a shape. Planning the API first is the cheapest way to keep it coherent.

Steps 1 to 3: scaffold, models and storage

Step 1: scaffold a minimal app

Have the copilot create a basic FastAPI application with a single health endpoint. This confirms the framework runs and gives you a foundation. Because FastAPI is well known, the copilot produces reliable scaffolding quickly. Review this tiny starting point before adding anything, so you stay in control from the first step.

Step 2: define the data models

Next, have the copilot create the models: your resources with their fields and types. FastAPI uses these models to validate requests and responses automatically, which catches errors early, and they give the database its structure. Review them before you build around them, because the endpoints and storage both hang on this backbone.

Step 3: add a SQLite database

Wire up storage so data persists between runs. SQLite is a good fit because it needs no separate server and lives in a single file, yet it is still a real database. The copilot can set up the tables from your models and write the code to read and write them.

Confirm that data saves and loads correctly before building endpoints on top. This is a checkpoint worth taking.

Steps 4 to 6: the endpoint, test and commit loop

Step 4: build one endpoint

Start the core loop with a single endpoint, for example creating a resource. Review exactly what the copilot generated so you fully understand each addition. Then continue through the rest of the REST operations, reading, updating and deleting, one endpoint at a time. Each endpoint connects the API to the database through your models. Small, reviewed additions accumulate into a complete REST API, and that is what keeps quality high in an agentic build.

Step 5: test that endpoint

Verify the endpoint immediately: does it return the right data, handle bad input and persist to the database? A tool like pytest makes this straightforward, FastAPI endpoints are easy to test, and the copilot can write the tests alongside the code. Testing each endpoint as you add it catches problems while they are isolated and cheap to fix.

Step 6: commit, then repeat

Lock in the working endpoint with a Git commit, then add the next endpoint, test it and commit again. A commit after each verified step means a later mistake costs one step rather than the whole build, which matters when an agent moves fast. Clear commit messages turn your history into a navigable record.

This build, test, commit rhythm is the heart of the workflow and ties into broader checkpointing and testing habits. Repeat it until the planned API is complete.

Adding an AI chat endpoint

The chat feature is just another endpoint, one that talks to a model. Have the copilot add a route that takes a user message, calls a language model and returns the reply. It follows the same request-response pattern as the rest of your API, and routing the model call through your back-end keeps the design clean. This is the point where your API connects to an external AI service, and adding it extends the API with intelligence.

Test the chat endpoint like every other one before you rely on it, since tests are what turn plausible code into verified code.

Keep the model API key on the server

The chat feature needs a model API key, and anyone who has that key can spend your balance. Keep it in a server-side environment variable, never in code or anything client-facing, and load it from a gitignored env file. This is the standard safe pattern, and getting it right from the start avoids the most common and costly mistake. Secure the key before you ship anything.

Step 7: add error handling once the endpoints work

When the core endpoints exist, harden them. Have the copilot add sensible responses for bad input, missing resources and failures, then test those error cases to confirm the back-end behaves well when things go wrong, not only when they go right. Add it deliberately after the core endpoints work, not before. Error handling is what separates a demo from a real back-end you can depend on.

Review at every step, not just at the end

Review is not a separate stage but a constant. Read the copilot’s code at each step, scaffold, models, storage and every endpoint, and confirm you understand it before building the next piece. Skipping review to move faster is how an AI-built back-end becomes a black box.

Followed consistently, the workflow becomes a comfortable rhythm: scaffold once, define models, add storage, then loop through endpoint, test, commit and review until the API is done and hardened. A daunting task turns into a series of small, confident steps. The copilot supplies the speed within each step, and the workflow supplies the structure. The result is a real back-end with persistent data and AI features, built fast but kept sound by your discipline.

How Do You Add Authentication to a FastAPI App Built Entirely With GitHub Copilot?

Authentication, verifying who a user is, is one area where you cannot just accept whatever GitHub Copilot generates, because a mistake here is a security hole, not a bug. FastAPI has solid, standard ways to handle auth, and Copilot can implement them quickly, but this is exactly the kind of code that demands careful review and testing. Here is how to add secure authentication to a FastAPI app built with Copilot, using proven patterns and real scrutiny rather than blind trust.

Why authentication needs extra care

Auth deserves more caution than ordinary features because the stakes are security. A subtle mistake, a weak password check, an exposed token, a missing protection, can let attackers in, and unlike a normal bug it may not be obvious until exploited. This is precisely where accepting AI code unreviewed is dangerous, and where staying accountable for the code matters most. Authentication is high-stakes code. Give it the extra care its risk demands. The security-critical nature of auth is why it needs your closest attention.

Understand it before you generate

Before having Copilot write auth, understand the basics yourself. Knowing roughly how authentication works, verifying credentials, issuing a token, checking it on protected requests, lets you review what the agent produces and spot mistakes. Generating security code you do not understand is asking for trouble, since you cannot evaluate it. A working grasp of the concepts is the prerequisite for adding auth safely with AI. Understand the flow before you generate it. Knowing how auth should work is what lets you judge whether Copilot got it right.

Use the standard approach

Stick to proven, standard authentication patterns rather than anything clever. FastAPI has well-documented support for token-based auth, commonly using signed tokens issued on login and checked on each request, and following that standard path means the security has been vetted by many. Asking Copilot to implement the conventional approach, not invent one, keeps you on safe ground. Standard auth patterns exist because they are trusted. Use the well-trodden path. Proven approaches are far safer than novel ones the agent might improvise for authentication.

Let Copilot scaffold the auth flow

With the approach chosen, let Copilot build the standard flow. Having it implement login that verifies credentials and issues a token, and the logic to check that token on protected requests, gets the structure in place quickly, connecting to your existing API endpoints. Copilot is genuinely helpful here, doing the boilerplate of a known pattern. Let it scaffold the conventional flow, then review closely. The agent builds the standard auth structure fast, and your job is to verify every security-relevant detail it produced.

Hash passwords, never store plain

One rule is non-negotiable: never store passwords as plain text. Passwords must be hashed with a strong, purpose-built algorithm so that even if the database leaks, the actual passwords are not exposed. Confirming Copilot uses proper password hashing, and not storing or logging raw passwords anywhere, is a critical review point. This is a mistake AI code can make, so check it explicitly. Hashed passwords are a hard requirement. Verify the hashing is done right, because plain-text passwords are one of the most serious and common security failures.

Protect the right endpoints

Authentication only helps if it actually guards your endpoints. Ensuring that the endpoints which need protection require a valid token, and that nothing sensitive is accessible without it, is essential, and it is easy for AI-generated code to leave a route unprotected. Reviewing which endpoints are guarded, and confirming the sensitive ones are, closes that gap. Auth that protects nothing is useless. Check that the protection is applied where it matters. Verifying every sensitive endpoint requires authentication is what makes the auth real rather than decorative.

Keep secrets safe

Auth relies on secrets, the signing key for tokens, any credentials, and these must be protected. Keeping them in server-side environment variables, never in code or the repository, prevents the exposure that would undermine the whole system, since a leaked signing key lets anyone forge tokens. Confirming Copilot loads secrets from the environment and did not hard-code them is a key check. Secrets are the foundation auth security rests on. Guard them rigorously. A leaked auth secret compromises every account, so keeping it safe is essential.

Test the authentication thoroughly

Auth needs more testing than ordinary features, not less. Testing that valid credentials work, invalid ones are rejected, protected endpoints refuse unauthenticated requests, and expired or tampered tokens fail confirms the auth actually secures the app. These tests, which Copilot can help write, verify the security really works rather than just appearing to. Thorough auth testing is what turns plausible security code into trusted security code. Test every path, especially the failures. Confirming that unauthorized access is actually blocked is the whole point of testing authentication.

Do not blindly trust AI security code

The overarching rule is heightened skepticism for security code. Because a mistake in auth is a vulnerability, reviewing Copilot’s security code more carefully than ordinary code, and not assuming it is correct because it looks right, is essential, echoing the best practices for reviewing AI output. If anything is unclear, verifying it against trusted documentation or a known-good pattern is worth the time. Security code earns extra scrutiny. Do not trust AI-generated auth blindly. The consequences of a missed flaw make careful review non-negotiable here.

How Do You Hook Up a React Frontend to a FastAPI Backend in a Full-Stack Kanban App?

Building a React front-end and a FastAPI back-end is only half the job, the app comes alive when you hook them together. In a Kanban app, that means the board fetches its columns and cards from the back-end and saves every move back, so the state is real and persistent. The connection is all about the API, plus a few practical details like CORS and base URLs. Here is how to hook up a React front-end to a FastAPI back-end in a full-stack Kanban app.

The connection is the API

The two halves connect through the back-end’s API, not shared code. The React front-end makes HTTP requests to FastAPI’s endpoints and uses the JSON it gets back, so hooking them up means having the front-end call the right endpoints for each action. Everything else is detail around that core exchange. Understanding that the API is the whole connection keeps the wiring conceptually simple. The front-end asks, the back-end answers, over HTTP. That request-response link is what you are building when you connect the halves.

Enable CORS on FastAPI

A first practical hurdle is CORS. Because the front-end and back-end run on different origins during development, browsers block the requests unless the back-end allows them, so you configure FastAPI’s CORS settings to permit your front-end’s origin. Without this, the connection fails with a confusing browser error even though the code looks right. Enabling CORS is the step people miss first. Configuring it correctly is what lets the browser actually talk to your API. CORS is the permission that makes cross-origin requests work in development.

Configure the base URL

The front-end needs to know where the back-end lives. Setting the API base URL, the address the front-end sends requests to, in one place, ideally from an environment variable, keeps it configurable between development and production. Hard-coding the URL scattered through the code makes it fragile, whereas one configured base URL is clean. Getting the base URL right is what points the front-end at the correct back-end. Configure it once and reuse it. A single, environment-driven base URL is the tidy way to tell the front-end where to call.

Fetch data from the back-end

The first real connection is reading data. Having the front-end send a GET request to fetch the board, its columns and cards, and render what comes back turns the static UI into a live board showing real data. This fetch-on-load is the moment the halves first talk. Using the framework’s data-fetching to call the endpoint and store the result in state is the standard pattern in React. Fetching the board’s data is the first sign the connection works. Seeing real data appear confirms the wiring is right.

Handle the Kanban actions

In a Kanban app specifically, each interaction maps to an API call. Creating a card posts to the cards endpoint, moving a card updates its column, deleting removes it, so wiring the board means connecting each action to the right request on your FastAPI back-end. Mapping every board action to an endpoint is the heart of the connection. Each drag, click, and edit becomes a call that keeps the back-end in sync. Handling all the Kanban actions through the API is what makes the whole board persistent and correct.

Add loading and error states

Real connections are not instant or infallible, so the UI should reflect that. Showing a loading state while a request is in flight and a clear message when one fails keeps the board usable when the network is slow or the back-end errors, rather than freezing or silently breaking. These states are part of connecting the halves properly, not an afterthought. Handling the in-between and failure cases makes the connection robust. A board that shows loading and handles errors feels solid, where one that assumes instant success feels broken.

Keep the API contract consistent

The connection only works if both halves agree on the data. Keeping the shapes the front-end expects and the back-end returns consistent, the same fields, the same structure, prevents the subtle bugs where the front-end reads a field the back-end never sent. This shared contract is what the whole connection rests on, so a clean project structure that keeps it visible helps. Consistency between the halves is essential. A matching contract is what lets the front-end and back-end understand each other reliably.

Test the connection and run both

Finally, verify the halves work together with both running. During development you run the FastAPI server and the React dev server at once, then test that the board loads, saves, and updates correctly end to end. Confirming each action actually persists to the back-end catches wiring mistakes. If something fails, the usual causes are CORS, a wrong base URL, or a contract mismatch, each with a clear fix. Testing the connection end to end is how you know the app is truly wired. A board that loads and saves with both servers running is a connected full-stack app.

How Do You Persist Kanban Board State Across Sessions Using a Proper Database Schema Instead of a JSON Blob?

When you first make a Kanban board persist, the tempting shortcut is to dump the whole board as one JSON blob in a single database field. It works at first, but it is fragile and does not scale. A proper schema, real tables for boards, columns, and cards with relationships between them, is what makes the state robust, queryable, and safe. Here is how to persist Kanban board state with a proper database schema instead of a JSON blob, and why the extra structure is worth it.

The JSON blob temptation

The blob approach is seductive because it is easy. You serialize the entire board, columns, cards, and all, into JSON and save it in one field, then load and parse it back when needed, with no schema to design. For a quick prototype it feels efficient, one field, one save. That simplicity is exactly why people reach for it. Understanding the appeal is fair, but the ease is front-loaded, and the problems show up as the app grows. The blob is the path of least resistance, which is not the same as the right path.

Why the blob is fragile

The JSON blob breaks down in several ways. You cannot query inside it, find all cards assigned to someone, without loading and parsing the whole thing, updating one card means rewriting the entire board, and two simultaneous saves can overwrite each other, losing data. There is also no integrity, nothing stops a malformed board. These limits make the blob fragile as soon as the app is real. The convenience hides serious weaknesses. A blob that works for a demo becomes a liability the moment you need to query, update precisely, or handle real use.

What a proper schema looks like

A proper schema breaks the board into related tables. A boards table, a columns table, and a cards table, each row a real entity with its own fields, replaces the single blob with structured, queryable data. Each card is its own row, each column its own row, linked to their parents. This is standard relational design, and an agent can set it up in SQLite easily. The schema turns an opaque blob into transparent, structured storage. Separate tables for the board’s parts are the foundation of robust persistence.

Relationships and foreign keys

The tables connect through relationships. A column belongs to a board and a card belongs to a column, expressed with foreign keys that link each row to its parent, so the database understands the structure rather than treating it as opaque text. These relationships enforce that every card has a valid column and every column a valid board, giving you integrity the blob cannot. Foreign keys are what turn separate tables into a coherent board. The relationships are what make the schema more than just three lists, they encode how the board actually fits together.

Handling card order

Kanban cards are ordered within a column, and a schema handles this cleanly. Giving each card a position or order field lets you store and change its place in the column with a simple update, rather than rewriting a whole ordered array as the blob would require. Moving a card becomes updating its column and position, one small, precise change. Handling order explicitly is a place the schema clearly beats the blob. A position field is how a relational board keeps its cards in the right sequence without rewriting everything on every move.

Why the schema wins

The schema’s advantages are decisive as the app grows. You can query precisely, find, filter, and count cards without loading the whole board, update a single card without touching the rest, rely on integrity to keep the data valid, and handle concurrent changes safely. These are exactly the things the blob cannot do. The structure that costs a little more up front pays off in every direction later, which is why real apps use schemas. The schema wins on queries, precise updates, integrity, and concurrency, everything that matters once the board is real.

Migrating from a blob

If you started with a blob, moving to a schema is a worthwhile migration. Designing the tables, then writing code to read the existing blobs and insert their contents as proper rows, converts your data without losing it. An agent can help write this migration, and doing it early, before the blob’s problems bite, is easiest. Migrating from blob to schema is a normal step in an app maturing. The sooner you move off the blob, the less data and code you have to convert. A one-time migration buys lasting robustness.

Let the agent design it, then review

An AI agent can design a solid schema quickly, but review it. Asking Copilot or Codex to propose tables for the board, columns, and cards with sensible relationships gives you a strong starting point, and then reviewing the schema, checking the relationships, fields, and constraints, is essential, since data structure is hard to change later. Getting the schema right early matters more than most code. Let the agent draft it, then scrutinize it carefully, applying sound API and data design judgment. A reviewed schema is a foundation you can trust.

Wiring the schema to the API

Finally, connect the schema to your endpoints. Having the back-end read and write these tables through your REST API, so creating a card inserts a row and moving one updates its column and position, is what makes the board persist correctly across sessions. Each API action becomes a precise database operation rather than a whole-board rewrite. Wiring the schema to the API is what turns structured storage into a working, persistent board. The endpoints and the schema together give you a Kanban app whose state is robustly saved and correctly updated every time.

Related guides
Build a Full-Stack App With GitHub Copilot: FastAPI, React and Next.js From Scratch
Docker for AI-Built Apps: Containers Explained, First Project and Production
How to Review and Test AI-Generated Code Before You Deploy It

Common questions