Bakery software with an API you can build against

A bakery of any size ends up with its data in more than one place. Orders arrive from a storefront and from a Shopify shop. An accountant wants numbers in a shape nobody in the kitchen recognises. A wholesale customer has a purchasing system that will happily send you a purchase order and would rather not send you an email. Someone wants a screen on the wall showing what is being made today.

Each of those is either a person retyping something, or an API call. Most bakery software gives you the first option and calls it an integration. This post is about the second: what an API is for if you run a bakery rather than write software, and the specific shape of the one ibakepro ships, including the part that will decide whether it is any use to you.

That is the whole shape, stated first because it decides which projects fit. Reporting, outbound sync and pushing records in from other systems are with the grain of this API, and the rest of this is for you.

What people build with it

None of these needs a large piece of work. Each is a few days for somebody who does this for a living.

• A nightly export of orders and expenses into whatever your accountant or your own spreadsheet wants.
• A screen in the kitchen showing today's production, refreshing itself.
• A wholesale customer's purchasing system sending its order straight in, instead of an email somebody retypes.
• A bridge from an order source ibakepro does not connect to yet.
• Your own website listing your products, priced from ibakepro rather than from a copy that goes stale.
• Expenses pushed in from wherever they start, if that is not ibakepro.

What it will and will not touch

You can read your catalogue, your customers, your orders and your expenses, and you can create new customers, orders and expenses. You can ask what dates you are bookable on. A website you build can search your live catalogue directly rather than keeping a stale copy of it, and it can price a cart and hand the shopper a page to pay on.

One detail worth knowing before someone builds against it. An order pushed in from another system keeps the prices that system sends, because if your prices are decided somewhere else, ibakepro should not argue with them. A cart priced for a web page is the opposite: ibakepro prices that itself, so a browser cannot tell you what something costs.

The two problems every integration hits

The first is the nightly catch-up. A sync should ask what changed since last night rather than pulling everything, and products, customers and expenses can all be asked exactly that. Without it you get a job that takes longer every week until someone turns it off.

The second is the send that might have worked. Your system pushes an order, the connection drops before it hears back, and now nobody knows whether that order exists. Send it again and you get the original back rather than a second order. That sounds like a small thing until it is a Saturday with two of the same cake on it.

Keys, and the one distinction that matters

Keys are created in Settings, under Integrations. You choose what each one can touch and you see it once.

The distinction worth understanding, because it decides what you can safely hand to someone building your website: one kind is for your own server and can do whatever you granted it. The other is safe to put in a public web page, and can only search your catalogue and open a checkout. It cannot write anything or reach the back office no matter what anyone ticks. If a developer asks you for a key for a public site, that is the one they should be getting.

Being told rather than asking

ibakepro can tell your system when something happens, across orders, customers, products, payments, counter sales, expenses and low stock, rather than making it ask every few minutes. That is the difference between the screen on the wall being right and being a few minutes behind.

Deliveries are signed so your developer can confirm they came from ibakepro, and anything missed while your system is down is retried. Subscribing to an event needs the same permission as reading the thing it carries.

What it costs, and where the real detail is

API keys and webhooks are on the Business plan. Version 1 of the API is retired, so an old integration still calling it is told so rather than failing quietly.

The endpoint by endpoint reference, the part a developer works from, is at docs.ibakepro.com. Hand them that. This post is the shape of the thing, so you can tell whether it is worth the conversation.

The honest version of the tradeoff: this API is good at getting data out of ibakepro and at putting records in from somewhere else. Build a nightly sync, a production dashboard, a wholesale ordering front end or a bridge from another order source and you are working with the grain. Editing that order five minutes later is work the dashboard keeps.