iiko API: How to Connect Your POS, 1C and Power BI in Kazakhstan
Contents
- What is iiko API and what reports can you get
- What data sources are needed to integrate iiko, Power BI, and 1C
- Why you need a unified catalog of dishes and locations
- How to reconcile POS, aggregators, and Kaspi
- How to set up data updates and verification
- What integration errors prevent trusting the report
- Who is responsible for access permissions and storage
- What to include in the contractor checklist
- Frequently asked questions
iiko API helps pull data for analytics, but connecting the POS system alone does not explain a restaurant's performance. To match sales, ingredient consumption, and cash receipts, you need aligned sources and rules. Start with a single closed period: it makes it easier to spot missing rows, conflicting names, and duplicated amounts.
Let's look at how to set up the integration of iiko, Power BI, and 1C for a restaurant in Kazakhstan. You will compile a data list, check dish and location catalogs, and ask the right questions to your contractor. This will help you accept the project based on verifiable calculations and transition it to ongoing maintenance.
In brief:
- For iiko OLAP reports, consider iikoServer API, verifying the method and permissions in the official documentation.
- Link POS, inventory, 1C, delivery aggregators, and payments using consistent periods and catalogs.
- Count a sale registered in the POS toward total revenue only once.
- For each source, display the upload date, completeness, and document closure status.
- Accept the integration after reconciling totals, running a reload test, and verifying corrections.
What is iiko API and what reports can you get
An API is an interface through which systems exchange data according to defined rules. For a restaurant owner, what matters is what data is accessible through the chosen interface, for what period, and with what permissions. These parameters determine which metrics you can calculate and verify.
iikoServer API provides access to OLAP reports, including hourly revenue and receipt counts. A published guide provides an example using the reports/olap method with the SALES type. This is an example from technical materials that must be verified against official iiko documentation for your specific version and installation. Example of retrieving OLAP reports
Request a sample response. Compare it with a standard POS report for the same closed day. Check the composition of transactions and the available level of detail. If you need dishes, discounts, or inventory data, add each requirement to your checklist. Do not assume all desired fields will be available in advance.
Check the purpose of iikoCloud API and iikoServer API separately. For generating OLAP reports, start with iikoServer. Confirm the current authorization method, endpoint, permissions, and limitations in the official documentation. Keep the technical assessment results together with your report requirements.
To view reports on a phone, iiko offers iikoDashboard. Report access permissions are configured separately. If this view already solves the owner's needs, use this capability. Criteria for choosing a standalone system are gathered in our comparison of Power BI and POS analytics.
What data sources are needed to integrate iiko, Power BI, and 1C
Start with business decisions. Checking sales requires POS data, while ingredient consumption also requires recipe cards and inventory records. To calculate location performance, determine where expenses will come from. Record the source of each metric and designate an employee to verify the source amount.
| Source | What the data is used for | What to check in a sample |
|---|---|---|
| iiko or r_keeper POS | Sales, receipts, and available POS events | Period, location, transaction mix, granularity, and total |
| Inventory and recipe cards | Standard and actual ingredient consumption | Units, recipe versions, balances, and document closing |
| 1C | Purchases and expenses tracked in your database | Document details, posting date, and location attribution |
| Aggregator portals | Orders, settlements, and available deductions | History, returns, and links to POS sales |
| Confirmed incoming payments, including Kaspi | Reconciling revenue against sales | Dates, refunds, and matching criteria |
| Excel plan | Revenue plan and agreed metrics | Version, period, structure, and responsible person |
This is a checklist of collection requirements. Confirm the structure of specific exports with your vendor and data owner. For r_keeper and 1C, request samples from your own setup. Choose a transfer method after validating the available data: file, API, or another agreed option.
In Almaty, Astana, and other cities across Kazakhstan, consolidating multiple locations requires a standardized list of operational expenses. Specify where rent and payroll are recorded, and how they are allocated to specific periods and venues. Keep amounts in tenge alongside the source document and calculation rule.
Why you need a unified catalog of dishes and locations
A unified catalog is an agreed list of entities and cross-system mappings. It connects a dish code in the POS system to the corresponding accounting and delivery item. For each location, specify a stable identifier and its corresponding labels across all sources. Relying solely on similar names is not enough to link data reliably.
Suppose a fictional chain calls a drink "Large Latte" in the POS and "Latte 400" in the delivery file. First, confirm with the person in charge that this is the same item with identical ingredients. Only after verification should you record the mapping. Any different volume or recipe must remain distinct.
Break down complex items. Check combo sets, add-ons, substitutions, and portion sizes if they exist in your source data. Agree on how you record combo sales and track component usage. Keep original item codes so you can restore individual rows prior to consolidation.
Designate a catalog owner. When opening a location, adding a dish, or renaming an item, they must verify mappings before the next review. Output unmatched records as a separate list. Show what amount or quantity cannot yet be reliably allocated, and set a clarification deadline.
For recipe cards, record effective dates and units of measure. A change to today's recipe must be checked separately against historical sales. The methodology for calculating standard versus actual food costs is covered in the article how to calculate food cost. Use these definitions when scoping the integration.
How to reconcile POS, aggregators, and Kaspi
Define the period cutoff. Agree on how to allocate post-midnight transactions, returns, and late documents. Preserve the original date and time wherever available. For each source, record the rule that maps a record to an operational day.
For Wolt, Glovo, and Yandex Eats, collect available data exports and reports from partner portals. Data structure and history depth depend on the service; verify them with the provider. Commission and advertising expenses depend on your contract. Confirm which withholding amounts you can link to an order or period.
If a delivery order is already recorded in the POS system, adding the sale again from the portal will inflate revenue. Use the aggregator report to verify the channel and settlements. If records do not link completely, move disputed rows to a separate reconciliation. Channel expenses are covered in the article on delivery margin.
Reconcile Kaspi receipts against POS sales using verified documents. First, align with your accountant on dates and return processing procedures. If amounts do not match, identify the explanation in the transactions. Keep open discrepancies logged so the next employee can continue the review from the same point.
If you also use guest acquisition data from 2GIS, define the basis for linking it to sales. The inquiry itself does not guarantee a matching receipt. Include only the connections you can confirm with available data in your calculation.
How to organize data updates and verification
Report freshness depends on source readiness, data transfer, processing, and rendering on screen. For your chosen Power BI setup, check refresh frequency and limitations with the provider. Availability, licensing, and terms of use in Kazakhstan also require separate confirmation.
Separate data loading from calculation readiness. Sales may already be loaded while warehouse documents are still being verified. Show both statuses. Confirm actual product consumption only after balances are reliable and stock movements are closed. That way, the manager will understand why a previously displayed total changed.
Agree on verification checks for each update.
- All expected locations and dates are present in the dataset.
- Sales totals match control reports under identical filters.
- Re-imported records do not increase the total.
- New menu items and locations have verified mappings.
- A modified document recalculates the required period with the documented basis preserved.
- If a data source is delayed, the last successful load and the open issue are visible.
Test these conditions on a copy of the data. Repeat the load for one period, make an agreed test adjustment, and compare the results. Specify who receives failure alerts and who restores the update. After recovery, repeat the reconciliation of control totals.
The dashboard views and review cadence a business owner needs are described in the article on restaurant owner dashboards. In the project scope, link each screen to a verified source and readiness status.
What integration errors undermine trust in the report
Conflicting revenue definitions. Sales before discounts are compared against totals after returns. Document the formula for each metric and repeat the reconciliation on the exact same set of transactions. Save the control report filters alongside the results.
Incorrect catalog mapping. Two dishes with the same name are merged even though portion sizes differ. Check source codes and recipes. Correct the mapping and recalculate affected periods, preserving the reason for the change.
Mixed units of measurement. Purchases in packs are compared with consumption in grams. Document the units of measurement and conversion factors. Verify them with purchasing and the kitchen before assessing product variance.
Lost retroactive changes. After a document is corrected, the past period remains unchanged on screen. Agree on which changes the data load tracks and how recalculations are triggered. Verify this during acceptance testing on a test document.
Hidden data gaps. A location has no data, yet the overall total appears complete. Display data completeness right next to the metric. Assign an owner to restore the source and flag any period that cannot yet be compared to closed ones.
Who manages access permissions and data storage
Map out data flow: source, transmission, processing, storage, backups, and reports. For each component, specify hosting location, owner, and user access levels. Include all intermediate services proposed by the contractor in the diagram.
Assign access by job role. Define who views their individual location, sees the entire chain, edits formulas, and manages connections. Test these roles with separate user accounts. Review foreign service data transfer, data residency, and storage procedures with your IT and legal teams based on the specific architecture.
Agree on exit terms in advance as well. Determine who owns access to source exports, formula definitions, and master data catalogs. Ask the provider to demonstrate how to hand off maintenance to another qualified specialist. Verify that you can continue operations using the agreed set of documentation and data.
What to include in the contractor checklist
Build the project brief around a single owner question and a closed reporting period. You can choose an overall management metrics framework from the restaurant analytics guide. For each deliverable, define the verification method and designate the stakeholder from your team who will sign off on it.
Prepare a control dataset with your team. Include a standard day, an available return example, a catalog change, and a document adjusted after the period was closed. For each scenario, record the expected outcome in advance. The reviewer needs to see raw line items and understand why the total changes. If a suitable event is missing from the selected period, agree to test on a data copy and clearly label the test scenario.
- Specify source versions, access permissions, available history, and verified data samples.
- Agree on formulas, time periods, discounts, returns, and delivery accounting rules.
- Provide menu and location directories along with the person responsible for mapping new entries.
- Verify revenue, receipt counts, and selected product consumption against source data.
- Test reload scenarios, past period corrections, and missing source data.
- Confirm user roles, the data storage architecture, and the handover process for ongoing support.
Conclude acceptance with a list of verified deliverables and known limitations. For any unresolved issue, document the consequence, owner, and next step. This ensures the team knows which calculations are ready for regular reviews and what still needs verification.
Before handoff, ask the future maintainer to independently locate the metric source and repeat the update. For steps that require the author's help, expand the standard operating procedure. Save it alongside formula descriptions and contact info for data source owners.
Coordinate sending a data sample to the contractor. Prepare anonymized files that preserve the field structure and relationships between records. Separately list excluded information so the reviewer understands sample limitations. Discuss direct access to live sources with IT based on the specific task and dataset. To validate formulas, record the expected total for the control period in advance. After loading, compare the total and row count, then inspect several raw transactions. If the total matched by chance due to two offsetting errors, this check will uncover the discrepancy before the report enters routine use.
Frequently asked questions
Is iiko API an out-of-the-box connection to Power BI?
An API provides a method for data exchange. Retrieving the required report, transforming it, and reconciling data must be confirmed for the chosen setup. Check a sample, access permissions, and results on a closed period before evaluating a full integration.
Can you combine iiko, r_keeper, and 1C?
First, obtain available samples and map locations, dishes, and periods. Identify the source for each metric. Confirm the feasibility of the chosen transfer method on your own setup with a test load.
Will data update in real time?
Check the update mode and limitations with your vendor for the chosen setup. Verify the entire pipeline all the way to the screen. Clearly display the loading time and document status so the owner understands the calculation status.
Do you need Power BI just to view iiko reports on your phone?
iiko includes iikoDashboard for viewing reports, with permissions configured separately. Check the key metrics directly on the owner's phone. Evaluate a dedicated BI system based on your needs for consolidating data sources and available calculations.
Who should fix errors in the dish catalog?
Designate an owner on the venue's side. They confirm the meaning of the item with the kitchen and accounting. The contractor applies the agreed mapping and shows which periods have been recalculated. Keep a record of the reason for the correction.
