Three things to build on the OLET API today

For most retailers, “connect our systems” still means one of two things. Export a CSV by hand and email it to someone. Or wait for a vendor to build the one specific integration you need, then wait again when it breaks.

Neither scales past a handful of tools, and both put someone else’s roadmap ahead of yours.

The OLET public API changes that. It is not a request form or a partner program: it is a documented HTTP API, live today, that anyone with a key can call. API access comes with the Growth plan, and a store admin creates the key. You do not need OLET’s permission to build against it, and you do not need to wait for a feature request to get picked up.

Here are three things you can actually build with it this week.

1. A stock sync between OLET and wherever else you sell

If you sell in more than one place, your stock count is only ever right in one of them. A customer buys the last one online while the till still shows two on the shelf, or a shipment gets counted in the warehouse system but never makes it into OLET.

The fix is a small script, not a platform. Read stock levels from OLET with GET /products/{id}/inventory, compare them against whatever system holds your other channel’s stock, and push the difference back with a stock write for the product that changed. Run it on a schedule, or trigger it from a webhook if your other system has one.

This does not need to be sophisticated. A one way sync that runs every fifteen minutes closes almost all of the gap that causes overselling, and it is the kind of script one developer can write in an afternoon once they have a key.

See the stock sync recipe for a worked example.

2. A nightly sales export that goes wherever your data lives

Every retailer eventually wants sales data somewhere other than the register: a spreadsheet for a bookkeeper, a warehouse for a BI tool, a dashboard for an owner who checks numbers before coffee.

The manual version of this is someone logging in and exporting a CSV, which means the data is only as fresh as whoever remembered to run it. The API version is a script that runs on a cron job overnight, pulls the day’s sales, and writes them wherever they need to go. Prices come back as whole cents, never as decimal dollars, so the export does not need a rounding step or a currency library to get the numbers right.

Once this exists, nobody has to remember to run anything. The data is just there in the morning.

See the sales export recipe for the shape of the request and the response.

3. An AI assistant that actually knows your store’s API

The newest use of the API is not a scheduled job at all. It is handing an AI coding assistant the OpenAPI spec and asking it to write the integration for you, or to answer a question about your store’s data on demand.

Because the spec is public and machine readable, a tool like Claude or another AI assistant can read it directly, understand every field on every operation, and write working code against it without a developer first explaining the API by hand. That collapses the time between “we should build this” and a working prototype from days to an afternoon.

See Build with AI for how to point an assistant at the spec and get useful code out the other end.

Where to start

All three of these start the same way: create an API key in the back office, then make your first call. The quickstart walks through creating a key, checking it works, and reading a product back, in about five minutes.

None of this requires a partnership, a sales call, or a queue. The API is there. What you build with it is up to you.