For developers
Exactly what Pricebreeze touches in WooCommerce
The questions a store's developer asks before saying yes, answered the way the code answers them.
One page, not documentation. If something is missing, tell us and it goes here.
Permissions, reads and writes
What it reads
- Products through the WooCommerce REST API, with a Read/Write key you create and revoke whenever you like.
- Variations of variable products, so a price list row can target the right one.
- Per product: id, sku, name, type, parent, price, regular price, sale price, stock status. Optionally one barcode field that you choose.
What it writes
- Two fields only: regular_price and stock_status. Nothing else is ever sent in a write request.
- Through products/batch and products/{parent}/variations/batch, exclusively in the update array. Batches of roughly 100, backing off when the store struggles.
- Never create, never delete. There is no path through the code that creates or removes a product.
Orders, customers, coupons, settings and users are neither requested nor read. If the key carries broader permissions, Pricebreeze does not use them.
Where the keys live and what protects them
Consumer key and secret are encrypted at the application layer with AES-256-GCM, above the database encryption. The encryption key lives in an environment variable, separate from the database.
Plaintext never reaches logs, error reports, URLs or the browser. The server opens it only at the moment of the call to your store.
Disconnecting deletes them from us. Independently of that, you can delete the key inside WordPress at any time and the connection stops immediately.
- AES-256-GCM, with integrity checking
- Tampered ciphertext does not open. It does not yield garbage.
- The ciphertext is bound to its destination
- Your store address is part of the encryption. If someone manages to change the address, the keys simply do not open. Added after our own penetration test.
- No calls to private addresses
- DNS is resolved before every connection and non-public addresses are refused. Redirects are not followed, so the check cannot be sidestepped.
- Two independent switches
- Revocation works from either side: from Pricebreeze and from WordPress.
What happens when the store is not as the user saw it
Minutes or hours can pass between review and write. Before writing, the system re-reads the products live and excludes anything that does not match. Every exclusion gets a code and appears in the report.
| Code | When | Result |
|---|---|---|
| ON_SALE | The product has an active sale price at the moment of writing. | No write. The discount your customer sees does not change silently. |
| STORE_CHANGED | The current price differs from the one the user had in front of them during review. | No write. The approval was for a different state. |
| MISSING_IN_STORE | The product is no longer returned by the store. | No write. No product is created and no other one is picked. |
| ALREADY_APPLIED | The requested price or stock status already holds. | No write. History does not fill up with changes that changed nothing. |
No exclusion is resolved automatically. The system does not recalculate, adjust or retry with a different price.
Tenant isolation
01
Row Level Security
Every table carries a tenant identifier and a policy in the database. A query outside your own workspace returns no rows, whoever sent it.
02
Column level grants
Columns the system owns, such as job state or quality flags, are not writable by a user even when the row belongs to them.
03
Server side checks
Every state-changing action goes through server code, with a role and plan check. The owner approves and pushes, a member prepares.
Browser code is not a secret: the key that reaches a visitor is designed to be public. That is why isolation does not rest on it, but on the three layers above, which live in the database and on the server.
Rate limits
Limits exist so the service cannot become a tool for attacking accounts, and so reading costs stay bounded. They are counted in the database, so they hold across every instance.
| Action | Limit |
|---|---|
| Sign in, per address and per email | 30 and 10 per 15 minutes |
| Account creation per address | 5 per hour |
| Sign-in link per email | 3 per hour |
| Uploads per workspace | 30 per hour |
How the model is used
Pinned model versions
Model identifiers are fixed in code, not latest. An upgrade is a tested decision, not something that happens while you sleep.
Structured output, against a schema
The model returns rows in a defined shape. Anything that breaks it is flagged and never quietly becomes a product row.
File content is data
The text of a price list never acts as an instruction. Cells that look like a model instruction or a spreadsheet formula are flagged and sent to review.
No arithmetic from the model
Prices, margins and rounding are computed by deterministic code, in whole cents. The model takes no part in any money calculation.
What does not exist
Worth knowing now, because none of these are in the plan for the current version.
- A public API into Pricebreeze
- Outgoing webhooks to your own systems
- Shopify or any platform other than WooCommerce
- Creating products in your store
- Any access to orders or customers
- SSO or SAML
- A real-time connection to a supplier API
- Full automation without human approval
If this holds up, the rest is the owner's call
Two more pages cover what they would ask: exactly what changes in the store, and how long setup takes.