Catalog
Show approved products, attributes, prices, and stock from the primary source.
↗Connect data to your project
Products, prices, stock, documents, and statuses stay in the source system. A website, catalog, or portal receives only approved fields and performs explicitly agreed actions.
What is verified today
We call a connection ready only when its scenario has been verified. Other systems begin with an assessment.
Available
Business.ru
A catalog can use products, images, prices and stock from Business.ru. Sending orders back requires separate configuration and testing.
Available for Russian accounts; contact the team to check your connection.
Review connection boundaries About Business.ru Reviewed: 2 November 2026Another accounting system or CRM
1C, Bitrix24, MoySklad, another CRM, or a custom system is not automatically ready. We first need the API, permissions, fields, limits, and required update frequency.
Describe your system ↗One source. Useful information on your website.
A connection is useful when a website must show company data or return a completed user action to the source system.
Source system→
The company continues to maintain data in an accounting system, CRM, or another source.
Approved fields→
Only the data required for the specific page and user action is transferred.
Website or service
A catalog, portal, or internal tool presents the data in a clear journey.
Example field mapping for a catalog. Actual fields depend on your source and the agreed connection.
| At the source | Example value | On the website |
|---|---|---|
| Product name | Essential cotton T-shirt | Catalog title and search |
| Image | Product photo | A recognizable item on the page |
| Specifications | Color · size · composition | Filters and product comparison |
| Price and stock | Approved commercial values | Current purchasing information |
Sending data back is a separate step
A request, order, or status change is returned only after the write path is checked separately.
Read and write access are checked separately. Being able to retrieve data does not mean the website may change it at the source.
The data scope follows the user task
A website does not need unrestricted access to the source. Start with the pages, actions, and smallest useful set of fields.
Client portal
Give each customer access to the statuses and documents they are allowed to see.
↗Request or order
Send the selected items and parameters instead of a context-free message.
↗Internal tool
Use the required directories and records in a team workflow.
↗- Products and sales
- Names, groups, attributes, images, prices, stock, and delivery terms.
- Customers and documents
- Statuses, invoices, contracts, specifications, and files available to that user.
- Team operations
- Requests, directories, owners, stages, and approval outcomes.
Review the exact exchange, not just the system name
Define the exchange before connecting a live source. A file or test dataset is enough to build the first version.
- 01
User journey
Which data a person sees and which action must happen on the website.
- 02
Access
Whether there is an API or verified connector, how authentication works, and which permissions can be limited.
- 03
Fields and rules
Which values are required, how records are matched, and who remains responsible for source data.
- 04
Load and limits
Request limits, data volume, delays, and the update frequency the source can support.
- 05
Failures
What customers and the team see when the source is temporarily unavailable.
- 06
Acceptance
How read, write, permissions, and recovery paths are tested before publishing.
Every connection needs explicit operating boundaries
Minimum permissions
The connection receives only the required fields and operations. Read access is not silently expanded to write access.
Agreed frequency
Updates may run on a schedule or an event. This follows source capabilities and is not promised in advance.
Clear failure state
On failure, show the agreed last-known state or an unavailable message. Never invent current data.
Short answers about integrations
Does every connection work in real time?
No. Frequency depends on the API, limits, and agreed journey. It is documented before launch.
Can we build the website before connecting a system?
Yes. A first version can use a file or test dataset, while the source connection is assessed separately.
Do we need to replace our primary system?
No. Your company continues to maintain data at the source, while Fluw uses only the agreed subset.
What happens when the source is unavailable?
Choose the behaviour before launch: show the last confirmed state, limit the action, or report that data is unavailable.
Name the system, the data, and the website action
That is enough to separate a ready connection from work that needs a technical assessment.