Where a mini app gets its data: tables and external sources
Lists in an app — products, services, a timetable, listings — are drawn from data rather than from layout. Here is where that data lives, who changes it, and what to do when you would rather keep it yourself.
A table inside the app
A project has tables: rows with columns, like any spreadsheet. A repeater block takes the rows and draws them as cards — which is why "add a product" means adding a row rather than building another screen.
Rows can be edited from a phone without opening the editor: that is the ordinary way to run a catalogue, a timetable or a price list. The owner can invite editors into the app’s data — they change rows without touching the project itself.
How many rows you may have depends on the plan. The ceiling is checked on write, so it is better known before a row fails to save.
Every table of the project can also be seen as one schema — the Data mode next to the canvas: cards with their columns, relations between tables as lines, the selected table’s rows below. A column is added right on the card, and a relation is dragged with the mouse.
Your own source
If the catalogue is already kept in a Google spreadsheet, it can be connected and the app reads from it. A file on Yandex Disk works the same way, as does any address answering with JSON — an export from your own system, for instance.
The point is not to keep a second copy of the data. If a manager updates products in a spreadsheet, let them keep doing it there and have the app pull it in.
We have no ready connectors to particular CRMs: what is connected is an address serving JSON, not an "integration with system X".
What stays with the visitor
Separately from your tables there are records the app keeps for the visitor themselves: a cart, favourites, an order history. They survive a reload because the person is identified by your bot’s signature — so the bot has to be connected.
Form submissions collect too: they reach your Telegram and stay in the submissions archive in the editor.
Other questions
- Which is better: an internal table or a Google spreadsheet?
- The internal one is simpler and is edited by the owner from a phone, right inside the app. An external one is better when the data is kept there anyway and changing the habit costs more than connecting the source.
- How often does external data refresh?
- The source is re-read on a schedule — how often depends on the plan — and at every publish. Instant synchronisation — change a row and everyone sees it that second — is not what to expect.
- How many rows can a list hold?
- A long list can be split into portions with a “Show more” button in the list’s settings. One table holds up to 5,000 rows, and the plan sets how many records you get in total.