Build with AI
You know the product.
Now you're the developer.
If you can design a program, negotiate a filing, or run an MGA, you already have the hard part. AI builders turn plain-English product thinking into working software — and Foundry gives them a safe, filed core to build against. What used to take a dev team a year now takes one product person a weekend.
Three steps, one weekend
1 — Get a key
Mint a free 30-day sandbox key right here. It talks to a real demo filing, not a mock — your first call returns a real premium.
2 — Open your AI builder
Start a project in Lovable or Replit. Both let you describe software in plain English and iterate by conversation.
3 — Paste the prompt
Give the builder our starter prompt and your key. It reads our machine-readable API spec itself and writes the calls for you.
The tools we recommend — and use ourselves
This entire platform was built with AI-assisted development. These are the two builders we point product people at first. (Full disclosure: these are our referral links.)
Fastest to a working app
Lovable
Describe your quote flow in a sentence and watch it appear. Paste our starter prompt and API spec URL and the agent writes the Foundry calls for you — you stay in product language the whole time. This is the tool we build in.
Start building in Lovable →
Most flexible
Replit
A full build-and-host environment with an AI agent that reads our OpenAPI spec, writes the integration, and deploys it — good when you want to peek at the code as you learn.
Start building in Replit →
Your starter prompt
Paste this into your builder along with your sandbox key. It points the agent at our machine-readable spec so it writes correct calls instead of guessing.
Build me a commercial insurance (BOP) quote app that calls the Sovereign Foundry API.
Everything you need is in this prompt — do not fetch any spec URL.
ENDPOINT
POST https://sovereignautoengine.com/api/public/v1/bop/quote
Headers: Authorization: Bearer <SOVEREIGN_FOUNDRY_API_KEY>, Content-Type: application/json
Keep the key server-side (env var / server function), never in browser code.
REQUEST BODY (all fields required)
{
"class_code": "retail" | "office" | "restaurant",
"protection_class": 1 | 2 | 3 | 4 | 5,
"building_limit": 400000, // whole dollars, 0 allowed
"contents_limit": 150000, // whole dollars, 0 allowed
"gl_limit": 500000 // 300000 | 500000 | 1000000 | 2000000
}
RESPONSE 201
{
"ok": true,
"premium_by_coverage": { "BLDG": 168000, "BPP": 76500, "GL": 42000 }, // integer CENTS
"fees_cents": 15000,
"total_cents": 301500,
"trace": [ { "step": "BLDG", "detail": "human-readable rating math" } ],
"product": "Foundry Demo Businessowners",
"state": "TN",
"product_version_id": "uuid",
"request_id": "req_..."
}
ERRORS: non-2xx returns { "ok": false, "error": "message" }. 401 = bad/expired key.
APP TO BUILD
A single-page form asking class of business, protection class, building limit,
contents limit, GL limit; on submit call the endpoint through a server route and show
premium by coverage, fees, total (format cents / 100 as USD), the rating trace lines,
and a Buy button placeholder. Money is integer cents everywhere — never use floats.Agent legibility: https://foundry.sovereignautoengine.com/openapi.json (OpenAPI 3 spec) · https://foundry.sovereignautoengine.com/llms.txt (compact summary)
Why the core underneath is safe to build on
Moving fast only works if the foundation doesn't move. Every premium your app books is rated through a filed, versioned rate plan; premium and cash live in separate ledgers; every signature carries an evidence record; every transaction is stamped at booking with its full dimension set. Your AI builder can get the screens wrong a hundred times — it cannot book a bad number, because the core validates everything it accepts.