# Scaffold an API Spec in Anypoint Code Builder (ACB) + VS Code Project Tour & Tips (Part 2) > Scaffold a Mule project from your published OpenAPI spec in Anypoint Code Builder, then tour the generated flows in both XML and UI views and run it locally. - **Watch:** https://www.youtube.com/watch?v=SIcxoyL5NtY - **Page:** https://prostdev.com/video/scaffold-api-spec-acb-project-tour - **Series:** Learn Anypoint Code Builder (ACB) - **Duration:** 11:07 ## About this video Scaffold a Mule project from your published OpenAPI spec in Anypoint Code Builder, then tour the generated flows in both XML and UI views and run it locally. ## Transcript ### Intro In the last video we designed a complete API specification using OpenAPI. Now it's time to scaffold it. In this video I'll show you how to take that spec from Anypoint Exchange, generate a full Mule project in Anypoint Code Builder, and get it running locally. But we're not stopping there — I'll walk you through what actually gets scaffolded, how to explore your flows in both XML and UI views, how to fix common project-setup issues, and how to start working like a real dev in VS Code with Git, Postman, error handling, and all the ACB essentials. By the end, your API will be running and you'll actually understand what's going on. ### Scaffolding from Exchange We finished our API spec and published it to Exchange — and remember there was a message asking whether to scaffold, and we selected No. So let's get that going now. In the MuleSoft tab, click **Implement an API**. (It doesn't matter whether the spec is on your computer; it's in Exchange.) Name the project something like `todo-api-impl`, select the project location, and since we're already signed in, search for "todo API", press Enter, and select your **To-Do Task API**. Click **Add asset**, leave the Mule runtime and Java version as default, and click **Create project**. ### What got scaffolded Once scaffolding finishes, you'll see all your flows. Note the **error handling** that's already there — this is the default for common errors: bad request, resource not found (404), method not allowed (405), not acceptable (406), unsupported media type (415), and so on. Each sets a target payload and an `httpStatus` variable. These error messages are created by default — you don't even define them in your API spec. There's a **listener** with a connection configuration and a path starting with `/api`, running on `localhost:8081`. We'll keep that for now and save best practices for a later issue. At the top is the **flow list** — one flow per method (the two GETs, the DELETE, the POST, and the PUT). There's also an **API Console** flow you can leave or ignore (a lot of people don't use it). You also get a Log4j config, test resources with some embedded sample data, an auto-created `.gitignore` (handy when you start using Git), the `mule-artifact.json` (don't edit it directly), and the POM. For any file under `src/main/mule`, right-click and check out **Open Mule project properties** — it's important: it shows what's in your `mule-artifact.json` in a nice UI, and it'll download runtimes or Java versions you don't already have. For example, I only have 4.9.6, but if I select another and click Apply, it downloads it. On the **Connectors** side you can see everything in your `pom.xml` (APIkit module, HTTP connector, sockets connector) — all added automatically by scaffolding — check available versions, and see which are incompatible with your runtime or Java. ### Cleaning up: .gitignore and source control To get rid of the embedded folders (they only create sample data), open the `.gitignore` and add `src/test/resources/embedded` (and anything else named "embedded"); save, and they disappear from the tree. To start a repo, go to **Source Control** and click **Initialize repo**. All files and folders show up (minus the embedded ones we ignored). Another folder you may not want in your repo is `.vscode` — right-click it and **Add to .gitignore** (it adds one file at a time, so it's easier to just ignore the whole folder). You don't have to commit right away, but you can see all the changes happening. ### Touring the canvas buttons Minimize the panels to see the canvas. At the top: **Open Agentforce** (skip for now), **Open changes** (related to Git/source control), **Open code editor** (to see the XML — you can close the canvas and only see XML if you prefer), and **Deploy to CloudHub** (not yet). If you have the XML open instead of the UI, you'll see an **Open canvas** button instead. A great tip: by default, opening a Mule config file opens the **UI** rather than the XML. To change that, click **Configure editors**, find `source.main.mule.xml`, and set it to default to the XML view. To go back to the canvas, set it to `mulesoft.pr-file.canvas`. (This tip was brought to you by Ryan Carter — thank you, Ryan!) Right-clicking a file also gives you: **Open canvas and code editor** (both at once), **Open Mule project properties**, **Deploy to CloudHub**, **Publish to Exchange**, **Export to Mule deployable JAR**, and **Export shareable JAR**. The difference: a deployable JAR can be deployed to CloudHub but not opened in Studio; a shareable JAR can be opened in an IDE to see the code. ### Running it locally Without changing anything, press the run/debug button to start the application and confirm everything is set up correctly. Once it's deployed, test it with the **Postcode** extension (or Postman, or any REST client). A GET to `localhost:8081/api/tasks` returns a `200` with an empty body (we haven't implemented anything yet). `localhost:8081/api/tasks/1` also returns `200` with nothing. Check the terminal logs and you'll see the GET requests coming through — the app is actually running. Then stop the application. ### Wrap-up We've scaffolded our API, explored everything ACB gives us out of the box, and you've got a much better feel for working inside VS Code with MuleSoft. We didn't touch any flow logic yet, but now you know how to find the flows, view and edit them in both UI and XML, set up your default views, run the app locally, and get started with source control and helpful extensions like Postcode and Postman. In the next video we'll start implementing real logic, beginning with the GET and POST methods, then the rest. If this helped you feel more confident in ACB, give it a thumbs up and drop a comment — I read every single one. And don't forget to subscribe so you don't miss the implementation video. That's all for this one — see you in the next video. Bye!