Building Custom OpenBOM Applications With AI

This guide explains how to build a small web application connected to the OpenBOM platform using an AI development agent. The recorded example uses Claude Code, but the approach is not Claude specific. Any equivalent environment works if it can read and write local files, run terminal commands, call web APIs, and deploy an application.

The application built in this guide provides catalog selection, item selection and information display, images and links from item data, per person authentication, editing of supported item properties, a QR code linking to each item page, printing a code for an individual item, and bulk generation of printable codes for a whole catalog.

The recorded build took approximately ninety minutes.

1. Prerequisites

You will need an OpenBOM account with permission to generate API credentials, an AI development environment with file system and terminal access, a source repository such as GitHub or GitLab, and a web hosting environment if teammates or mobile devices need to reach the application.

The video uses Claude Code, GitHub, and Render. These are examples rather than requirements.

No programming knowledge is required. You do need to describe outcomes precisely and to make the architectural decisions in section 3.

2. Start with the requirement, not the technology

Do not begin by choosing frameworks. Describe the outcome you want.

A useful opening prompt:

I want to build a simple web application integrated with OpenBOM. I have catalogs containing items identified by part numbers. I want a page where I can find an item and display its information. I also want each item page to have a QR code pointing back to this application, so I can print the code, attach it to a physical object, and scan it later.

Then add one more instruction that matters more than the rest: ask the agent to investigate the OpenBOM public API and propose an architecture before writing anything.

That instruction converts the agent from guessing to reading documentation. What it reports back becomes your design constraint rather than a surprise in week three.

3. Answer the architecture questions deliberately

The agent will ask before it proposes a plan, and your answers change the architecture. In the recorded session it asked three.

Who will actually use this app? One person or a team. This determines whether identity is needed at all, and it carries a second question inside it: if several people use the application, does it matter who did what? If yes, you need per person login. If no, an application level key alone is enough.

Does this need to work away from your own computer? For example from a phone on the shop floor, or from home. If yes, localhost is insufficient. A locally running application is unreachable the moment your machine sleeps.

Will the application ever change data in OpenBOM, or is it purely for looking things up? A read only viewer is simpler and far safer than an editor.

The example answered team with attribution required, yes it must run remotely, and yes it edits. That produces a specific model. One application level key and secret authenticates the application to OpenBOM, each teammate additionally signs in with their own OpenBOM credentials, and OpenBOM change history records the individual rather than the key owner.

If you are the only user and the application is read only, skip authentication entirely.

4. Create OpenBOM API credentials

In the OpenBOM application, open the Administration area and go to API Keys. Create a new application key, enter your email, and give it a meaningful description such as “Item Info Application”.

You will receive an access key and a secret key. Copy both immediately. The secret is displayed once and never shown again. If you lose it, revoke the credential and generate a new one.

Create a separate credential for each application. Six months from now the description field is the only thing that tells you which key belongs to which application when you need to revoke one.

The security rule that matters most

Do not paste API secrets into the AI conversation. A good agent will refuse, and in the recorded session it did exactly that.

The correct flow: the agent creates a local environment file, typically named .env, and tells you where it is. You paste the access key and secret into that file yourself. You save it. You tell the agent the file is updated. The agent never sees the values.

Confirm the environment file is excluded from source control before you commit anything. If a credential is ever exposed, including in a screen recording, revoke it and issue a new one.

5. Prove the connection before building anything

Ask the agent to connect to OpenBOM and validate the API responses.

Prove this chain first: credentials, API connection, catalog data, item data. In the recorded session the agent confirmed the credentials worked, reported the number of catalogs found, and examined how item information is structured.

The endpoints it worked with were a call to list catalogs, a call to pull a full catalog’s contents, and a call to fetch a single item by part number within a specific catalog. Part number is the right identifier to build around. Confirm the current endpoint shapes against the OpenBOM API documentation rather than relying on this guide, since the API continues to develop.

Do not skip this. Verifying credentials before construction catches a wrong key before you have built anything on top of it, and interface work becomes far easier once the data path is known good.

6. Build the first version, then react to it

Once credentials verify, the agent installs missing runtime and dependencies and builds a first working version. You approve the commands it runs. This step is largely unattended.

Expect the first version to function and to look poor. That is the correct place to be.

To improve it, screenshot the current interface, attach it, and describe the problem. Two approaches work. Describe the outcome in words, for example “improve this based on current interface design conventions.” Or find an interface you like anywhere on the web, screenshot it, and attach it as a reference to imitate. The second gives you considerably more control.

You do not need a complete interface specification before starting. Generate something, look at it, and say what should change.

7. Extend one capability at a time

Small specific requests outperform large vague ones. The recorded example added these in sequence.

Images and reference links in the item view, since the first version rendered them as raw values.

Part number together with description in the item selector, because a list of bare part numbers is unusable to a human.

Item count beside each catalog name in the catalog selector.

Pasted OpenBOM item URL parsing. There is no global endpoint that searches every item across every catalog, so a search page has to let you pick a catalog first and search within it, or pull everything into the application once and search locally when the total item count is manageable. OpenBOM item URLs carry catalog context, which gives you a third option: accept a pasted link and select the correct catalog automatically. Copy the item link in OpenBOM, paste it into your application, and skip catalog navigation. Keep both paths available, since each is faster in different situations. Check current OpenBOM API and URL documentation when you implement this, as formats evolve.

The general pattern is worth naming, because it recurs later: OpenBOM context flows into the custom application. That is the same idea that contextual User Defined Commands will use.

8. Add authentication and editing

If the application only shows non sensitive information, authentication requirements are simple. If it exposes private company data or permits modification, authentication must be designed before deployment rather than after.

When you request editable fields on an application that requires attribution, the agent will build the login flow as a dependency, because an edit is only meaningful when a user is identified. Expect it to protect certain fields from editing on its own reasoning, and confirm those choices match your intent.

Create a small test catalog with two or three throwaway items before testing writes. Do not test against production data.

Verify in both directions. Change an item in your application and confirm the new value appears in OpenBOM after a refresh, attributed to the signed in individual. Then change an item in OpenBOM and confirm your application reflects it. This proves the application is operating on OpenBOM data rather than a local copy.

If a value does not appear, report exactly what you observed, for example “on save I can see the request data, but the value in OpenBOM is unchanged after refresh, is the write actually implemented.” Specific observations produce fast fixes. In the recorded session that exact report surfaced a real bug and it was corrected immediately.

9. Put the application in source control

Once it works locally, ask the agent to create a private repository, generate an appropriate .gitignore, confirm secrets are not committed, commit, and push. It handles this without you visiting the repository host, provided you are already authenticated locally.

Private is the correct default for internal tooling even though your secrets live outside the repository.

10. Control when changes go live

By default your agent may commit and deploy immediately after each change. Set expectations early:

Do not push to hosting until I confirm the result. I will ask you when to update the repository.

The workflow you want is change, local test, review, commit, deploy. Automatic deployment is convenient during initial construction and inappropriate once other people depend on the application.

11. Deploy the application

The recorded example uses Render. Any hosting platform works.

1. Create a hosting account if you do not have one
2. Create a new deployment from your repository
3. Grant the hosting service access to that specific repository. This is the step most likely to stall. If your repository host restricts access to selected repositories, you must explicitly add the new one to the permitted list
4. Select the main branch
5. Enter the API access key, secret key, and a session key as environment variables in the hosting configuration, never in source
6. Deploy

After the first deployment, every pushed change triggers an automatic redeployment. In the recorded session a mobile layout fix went from description to live site in roughly two minutes.

Free hosting tiers typically sleep after a period of inactivity and take a short time to wake on the next request. That is acceptable for evaluation. Move to a paid tier once people depend on availability. Verify current tier behavior with your provider, since these terms change.

After deployment, verify the complete workflow from a different device.

12. Close the exposure gap before sharing the URL

This is the most important section in this guide.

A deployed application sits at a public URL and anyone holding that URL can open it. In the recorded example, viewing catalog data required no login and only editing was protected, which means item data was readable by anyone with the link. The application’s own credential was doing the talking to OpenBOM.

If your catalog data should not be public, make login the entry point. Require authentication before any page renders data, issue an access token only after successful sign in, and reject every data request without a valid token. This is how OpenBOM itself behaves.

Verify by opening the URL in a private browser window where you are not signed in. Do not treat an obscure URL as security.

13. Fix the mobile experience

Open the deployed URL on a phone. Layout problems invisible on a desktop monitor are obvious immediately on a narrow screen.

The repair loop is identical to section 6. Screenshot the problem on the phone, attach it, describe what is wrong, for example “on mobile the content extends beyond the container, make the layout responsive.” Push, wait for redeployment, refresh on the phone.

14. Generate and print QR codes

Once every item has a stable application URL, the physical to digital chain becomes: physical item, QR code, web application, OpenBOM item information.

A note on OpenBOM’s own QR codes. Codes and item links rendered inside the OpenBOM interface point at OpenBOM URLs, and the identifiers in those URLs are not guaranteed to resolve through the public API. They cannot be reused to open your application. Your application generates its own codes, encoding catalog and part number and pointing at its own item pages.

Single item printing. Ask for a print command on the item page and specify the label layout explicitly: what sits above the code, what sits below, whether catalog name and description appear. Vague layout instructions produce layouts you did not want. Iterate with specific corrections. The advantage of owning the application is that the label can be designed around your actual business process.

Bulk printing. Printing one item at a time stops being viable quickly. Ask for printable QR codes for every item in the selected catalog. In the recorded session the agent chose to create a dedicated print page rather than a button on the search page, which was a reasonable interpretation. Specify the format you want.

Test by scanning with a phone. If a code fails, check the URL it encodes. A code generated while testing locally encodes a localhost address that no phone can reach. Codes must be generated from the deployed application.

This sequence illustrates the general development pattern worth internalizing: build the smallest useful capability first, then describe the next workflow bottleneck to the agent.

15. Production checklist

Before real users depend on the application:

1. API secrets are absent from source code and repository history
2. Secrets exist only in your local environment file and in hosting environment configuration
3. The repository is private
4. Opening the URL in a private browser window without signing in reveals nothing you would not publish
5. Users hold only the permissions they require
6. Edits appear correctly in OpenBOM and are attributed to the correct individual
7. The application is served over HTTPS
8. Logs contain no passwords, tokens, or secrets
9. Any credential exposed during development, including in a screen recording, has been revoked
10. Printed QR codes scan and resolve to the deployed application, not to localhost
11. The layout is usable on a phone
12. The application has been tested independently of the developer’s local machine
13. You have moved off a sleeping free tier if availability matters

The video deliberately focuses on demonstrating what is possible. A production deployment deserves the same security, review, and testing you would apply to any business application.

16. Where to go next

Item Info and QR printing are starting points. The same pattern supports manufacturing and assembly instructions, shop floor item lookup, inspection and quality workflows, supplier information views, RFQ preparation, inventory operations, specialized reports, engineering reviews, custom data collection, and mobile workflows.

The architecture stays constant: OpenBOM data, OpenBOM API, AI generated application, your workflow. The limiting factor is what the platform APIs expose, and that surface continues to grow.

The goal is not to rebuild OpenBOM outside OpenBOM. The goal is to make the specialized last mile applications your organization needs dramatically cheaper to create.

Roadmap, not currently available. OpenBOM is planning to extend User Defined Commands so they can invoke your custom applications contextually, passing the item, catalog, or BOM you are currently viewing. Longer term, OpenBOM is exploring hosting and executing customer built applications as part of the OpenBOM environment itself. Neither capability exists today.

Start building

Everything in this guide runs on the OpenBOM public API, which is available to you today.

Create your OpenBOM account, generate an API key under Administration, and build the application your process actually needs. If you build something, we would like to see it.

openbom.com