> ## Documentation Index
> Fetch the complete documentation index at: https://docs.brandgate.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Integration model

> How BrandGate's data fits together and which system owns what. The same model for every ERP and tool.

Every integration, whether an ERP, an accounting system or your own software, uses the same small set of objects and the same rules. Learn them once and any system is connected the same way.

## The objects

| Object | What it is | Matched on |
| - | - | - |
| **Product** | An item the brand sells, with price, stock status and minimum order | `sku` |
| **Inventory** | Stock quantity per SKU | `sku` |
| **Customer** | A reseller who orders from the brand | BrandGate `id` (and the ERP's customer number where supported) |
| **Order** | A purchase with lines, VAT and totals | BrandGate `id`; the ERP's number is stored on acknowledgement |
| **Invoice** | Created from an order, with lines, totals and a payment reference | BrandGate `id` |

The exact fields, endpoints and which of them can be written are in the [API reference](/api-reference/orders/list-orders), which is generated from the contracts and always up to date.

## Who owns what

The rule is simple: **one system owns each piece of data**, and the other one follows. Two systems writing the same field is where syncs go wrong.

| Data | Owner by default | The other system |
| - | - | - |
| Orders | BrandGate (resellers order there) | ERP reads them and acknowledges with its own order number |
| Stock levels | The ERP | BrandGate shows them. See `inventory_managed_by_erp` |
| Invoices and payments | BrandGate creates, the ERP books | ERP reads them and books them |
| Product master data, base prices, price lists, customers, delivery status | The ERP, when it sends them with the [send-data endpoints](/guides/send-data) | BrandGate shows them; people should not edit these fields in BrandGate |

> [!NOTE]
>
> If you integrate products, prices or customers, agree with the company which system is the source of truth **before** you build. The pages for each system under [Integrations](/integrations/overview) state the rules for that system.

## Sync patterns

Use all three together; none of them alone is enough.

> **[Webhooks](/webhooks)**
>
> BrandGate tells you when something changed. Fast, but a single delivery can be missed.

> **[Catch-up polling](/pagination)**
>
> Every few minutes, read what changed with `updated_since`. This guarantees nothing is lost.

> **[Idempotent writes](/errors)**
>
> Repeating a write is safe, so a retry after a crash never duplicates anything.

### Idempotency in practice

Store BrandGate's `id` for each order **in your own system, with a uniqueness rule**. Before you create an order, look it up by that id. If it exists, reuse it; if not, create it and then acknowledge. If you crash between those steps, the retry finds your order instead of creating a second one.

## Environments and test data

Build and test against a test company, never a customer's live data. Ask BrandGate for a test company, then the company creates the key under **Settings → Integrations** (or **Settings → Developers**), or ask through [brandgate.dev/contact](https://www.brandgate.dev/contact). Switch to the customer's key or OAuth connection only at go-live.

## Two ways to get access

| | API key | OAuth connection |
| - | - | - |
| For | One company's own integration | A product used by many brands |
| Created by | A company admin in **Settings → Integrations** or **Settings → Developers** | Each company approves your app |
| Details | [API keys](/authentication) | [OAuth for partners](/oauth) |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.