What ibakepro connects to

Every connection here has a direction, and it is worth knowing which

An integration is only useful if you know which way it moves data, because that is what decides where you fix a mistake: in ibakepro, or in the other system. An accounting connection that pushes out is a different thing to live with than a shop connection that pulls in, even though both appear as a card with a connect button.

They all live in Settings, then Integrations, as a stack of cards, and each one below is described by its direction first.

Card payments run through your own account

Stripe connects through your own Stripe account. The card then shows which account it is attached to, whether it is live or test and whether Stripe has enabled charges, so a half-finished onboarding is visible before a customer meets it at checkout.

PayPal and Square have cards in the same list, and Venmo rides on the PayPal connection in US accounts rather than connecting separately. Both are built, and both currently show a coming soon badge in place of a connect button.

Expenses go out to your accounting platform, and nothing comes back

The accounting card lists Xero, MYOB and QuickBooks Online. Xero is the one open to connect today, with an organisation picker if your login has more than one, and a mapping from your ibakepro expense categories to your own chart of accounts. The other two are coming soon, and badged that way.

The direction is out. ibakepro pushes submitted expenses to your accounting platform and reads nothing back. A daily sales summary is coming soon. Full detail is in accounting sync.

Shopify orders come in, your catalogue does not go out

Shopify runs the other way: orders and customers come in, and nothing about your catalogue is written back out. Order and customer webhooks are registered when you connect and removed when you disconnect, so there is nothing to set up on the Shopify side.

In the product builder each of your variants can be linked to a specific Shopify variant, which is what lets an imported line item pick up the right recipe, cost and stock draw instead of arriving as a name and a price. And because a made-to-order bakery cannot work from an order with no date, a scheduled check alerts you when a Shopify order arrives without an event date. Shopify is on the Business plan and is currently badged coming soon.

Google Calendar is written to, never read

Google Calendar is the only calendar provider, on every plan. Four switches decide what it writes: orders on their event or delivery date, tasks on their due date, blocked dates as busy time and stock reorder reminders.

Social accounts connect once and post from ibakepro

One Meta sign-in connects Instagram and Facebook. TikTok connects on its own. A Google Business Profile card for review management is badged coming soon.

Carriers and a shared pantry sit in the same list

Two more cards live alongside the rest: your postage carrier accounts, and a pantry shared between two ibakepro accounts.

The public API reads and creates, and that is all

The API is v2. Version 1 is retired.

Keys are made in Settings, Integrations, under Developers. There are two kinds. A secret key is for your own server and can do anything you grant it. A publishable key is safe to put in a web page, and can only read your catalogue, read reference data, price a cart and open a checkout. A publishable key can never write, and never reach anything back-office, whatever you tick when you create it. Each key belongs to one region and cannot be pointed at another region's data by changing a URL, and you see a key once, when it is created.

What you can reach: products, customers, orders, expenses, availability, reference data (payment methods, categories, time slots, blocked dates, custom field definitions), a product search endpoint and a hosted checkout endpoint.

What you can do: read products. Read and create customers, orders and expenses. Create a checkout session.

Long lists are paged, and a partly filled page never reads as the end of the list, so a nightly sync does not stop halfway and believe it has finished. Creating a record is safe to retry: if your side times out and sends the same request again, you get the original record back rather than a second one.

One thing to design around: an order posted from your own server with a secret key keeps your prices. Line prices, tax and totals are written as you sent them. The checkout endpoint is the opposite, because a browser calls it with a publishable key: it prices the cart again on the server and hands back a hosted checkout page, creating no order and taking no payment.

Webhooks tell your system the moment something happens

Twenty events are subscribable, across orders, customers, products, payments, quick sales, expenses and low inventory. That is the difference between a production screen that is current and one that asks every ten minutes.

Each delivery is signed, so your system can confirm it came from ibakepro and not from somebody imitating it, and a delivery your endpoint misses is retried across the following day rather than dropped. You can rotate an endpoint's secret without a gap in deliveries. Records are kept thirty days, and the card shows delivery counts and a test send button.

Subscribing is treated as a read. Subscribing to a customer event needs the same permission as fetching a customer, because the payload is a customer record including marketing consent. Endpoint addresses are checked too, so a webhook can only be aimed at your own public address.

API keys and webhooks are both on the Business plan. The endpoint by endpoint reference, the one to hand to a developer, is at docs.ibakepro.com.