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

# 99Food as a data source

> Bring your 99Food stores, menus, financial entries, weekly payouts and accepted orders to Nekt.

99Food (99 Delivery) is a food delivery marketplace in Brazil. Its Open Platform lets an approved application read the data of the stores linked to it. This connector uses **your own 99Food application** to read your stores, menus, the financial entries of each order (revenue, refunds, fees and commissions), the weekly payouts, and the details of the orders your stores accepted.

> [!NOTE]
>
> The connector only reads data. It never confirms, cancels or changes orders, never changes stores or menus, and never links or unlinks stores.

## Before you start

> [!WARNING]
>
> Read these points before you add the source. They come from how 99Food's Open Platform works.

* **You need your own 99Food application.** The App ID and App Secret come from an application created in the [99Food developer portal](https://developer-food.99app.com/pt-BR/openapi) by a company that 99Food approved as a partner (99Food asks for a business agreement, an NDA and a review of the company). If you do not have one, ask your 99Food representative. Nekt does not provide this application.
* **Each store can be linked to only one application.** Linking a store to a new application unlinks it from the one it uses today (for example, the POS system that receives your orders), and that system stops receiving the store's orders. Use an application that is already linked to your stores, or one that does not take your stores away from your POS. Check this with your 99Food representative or your POS provider before linking anything.
* **The connector never reads or confirms the order queue.** 99Food sends new orders to the application's own system. The connector does not touch that flow: it finds the orders in the financial data and reads each one by its number. That is why only orders your stores **accepted** appear, and only after they appear in the financial data.
* **Reviews are not available.** 99Food does not offer customer reviews or ratings to applications.
* **Financial data covers only the last three months.** 99Food does not return older financial entries or payouts.

## Configuring 99Food as a Source

In the [Sources](https://app.nekt.ai/sources) tab, click on the "Add source" button located on the top right of your screen. Then, select the 99Food option from the list of connectors.

Click **Next** and you'll be prompted to add your access.

### 1. Add account access

In the 99Food developer portal, open **Application Management** and the production application your stores are linked to. Copy its App ID and App Secret. Under **Store Management** you can see the App Shop ID of each linked store.

The following configurations are available:

* **App ID**: The App ID of your 99Food application.
* **App Secret**: The App Secret of the same application.
* **Start Date**: Earliest date of the financial data to read. 99Food only keeps the last three months, so an older date is read from three months ago.
* **Order Details Backfill (days)**: How many days of orders the Orders table reads on its first sync (1 to 88, 7 by default). 99Food only lets orders be read one at a time, so every day of backfill makes the first sync longer.
* **Max Orders per Sync** (advanced): The most orders the Orders table reads in one sync (100 to 20,000; 1,500 by default, about 1.7 hours). Orders left over are read by the next syncs.
* **Store IDs** (advanced): The App Shop IDs of the stores to read. Leave it empty to read every store linked to the application.

| Tables | What 99Food must allow for your application |
| - | - |
| Stores, Store Details, Menus, Menu Categories, Menu Items, Menu Modifier Groups | Store and menu access |
| Financial Entries, Weekly Settlements | The Financial API |
| Orders, Order Items | The Financial API and order details |

> [!WARNING]
>
> If 99Food does not allow your application to read a group of tables, those tables are skipped (the sync log names them) and the other tables keep syncing. Ask your 99Food representative to enable it for the application, or deselect those tables.

> [!TIP]
>
> 99Food allows very few requests per minute for each application, and your POS uses the same allowance to confirm orders on time. To leave room for it, the connector uses at most about a third of each limit: expect about three minutes per store for Store Details and for the menu tables, and about four seconds per order for Orders. Schedule this source outside your stores' peak hours (for example, early in the morning).
>
> The first sync of Orders reads every order of the backfill days. Later syncs read the orders with new financial entries since the last sync (including entries that arrive a few hours late), and orders still in progress at the last sync. Each sync reads at most **Max Orders per Sync** orders; if more are waiting, the next syncs continue where it stopped.

#### Sizing for large networks

* **Orders per day must stay below Max Orders per Sync × syncs per day.** For example, 300 stores with 20 orders a day each (6,000 orders) need a Max Orders per Sync of 3,000 with two syncs a day, or 1,500 with four. At about 4 seconds per order, 1,500 orders take about 1.7 hours.
* **Each store adds about 7 to 8 minutes per sync** when every table is selected (access token, store details and menu), before orders: 10 stores take about 1.3 hours, 50 stores about 6 to 7 hours. With many stores, deselect Store Details and the menu tables here and sync them in a second 99Food source scheduled once a day or less, at a time when the main source is not running (both share the same 99Food limits).
* **If the Orders table falls behind**, the sync log warns when the orders waiting grow from one sync to the next, or when the oldest is more than 30 days old. Raise Max Orders per Sync or schedule more syncs: 99Food only keeps three months of financial data, so orders that fall further behind than that can no longer be read.

Once you're done, click **Next**.

### 2. Select streams

Choose which data streams you want to sync. For faster extractions, select only the streams that are relevant to your analysis. You can select entire groups of streams or pick specific ones.

> Tip: The stream can be found more easily by typing its name.

Select the streams and click **Next**.

### 3. Configure data streams

Customize how you want your data to appear in your catalog. Select the desired layer where the data will be placed, a folder to organize it inside the layer, a name for each table (which will effectively contain the fetched data) and the type of sync.

* **Layer**: choose between the existing layers on your catalog. This is where you will find your new extracted tables as the extraction runs successfully.
* **Folder**: a folder can be created inside the selected layer to group all tables being created from this new data source.
* **Table name**: we suggest a name, but feel free to customize it. You have the option to add a **prefix** to all tables at once and make this process faster!
* **Sync Type**: you can choose between INCREMENTAL and FULL\_TABLE.
  * Incremental: every time the extraction happens, we'll get only the new data, which is good if, for example, you want to keep every record ever fetched.
  * Full table: every time the extraction happens, we'll get the current state of the data, which is good if, for example, you don't want to have deleted data in your catalog.

> [!WARNING]
>
> Keep Financial Entries, Weekly Settlements, Orders and Order Items as INCREMENTAL, and do not run a Full Sync or schedule an Additional Full Sync for them. 99Food only returns the last three months (Orders: the backfill days), so a full sync would replace the table with that period and drop the older history your regular syncs kept.

Once you are done configuring, click **Next**.

### 4. Configure data source

Describe your data source for easy identification within your organization, not exceeding 140 characters.

To define your [Trigger](https://docs.nekt.com/runs/scheduling-and-triggers.md), consider how often you want data to be extracted from this source. This decision usually depends on how frequently you need the new table data updated (every day, once a week, or only at specific times).

Optionally, you can define some additional settings:

* Configure Delta Log Retention and determine for how long we should store old states of this table as it gets updated. Read more about this resource [here](https://docs.nekt.com/get-started/core-concepts/resource-control).

Once you are ready, click **Next** to finalize the setup.

### 5. Check your new source

You can view your new source on the [Sources](https://app.nekt.ai/sources) page. If needed, manually trigger the source extraction by clicking on the arrow button. Once executed, your data will appear in your Catalog.

> [!WARNING]
>
> For you to be able to see it on your [Catalog](https://app.nekt.ai/catalog), you need at least one successful source run.

# Streams and Fields

## Available streams

The table below lists every stream and its **slug** (the exact identifier to pass when creating the source via API).

| Stream | Slug | Description |
| - | - | - |
| Stores | `stores` | Stores linked to your 99Food application. |
| Store Details | `store_details` | Profile, address, opening hours and status of each store. |
| Menus | `menus` | Menus of each store. |
| Menu Categories | `menu_categories` | Categories of each menu, with their items in display order. |
| Menu Items | `menu_items` | Items of the menu with price, availability and selling hours. |
| Menu Modifier Groups | `menu_modifier_groups` | Option groups (add-ons, sizes) and their items. |
| Financial Entries | `financial_entries` | Every financial entry of each store: order revenue, refunds, commissions, fees, subsidies and other charges, with the amount settled to the store. Incremental; last three months. |
| Weekly Settlements | `weekly_settlements` | Weekly payouts to each store. Incremental; last three months. |
| Orders | `orders` | Orders the stores accepted, with status, prices, payment, customer address and promotions. Incremental. |
| Order Items | `order_items` | Item lines of each order, with options and promotions. Incremental. |

## Things to know

* **Amounts are in cents.** Every amount is an integer in the smallest currency unit, exactly as 99Food sends it: `1990` means R\$ 19.90. The commission rate is in hundredths of a percent (`3500` means 35%).
* **Identifiers are text.** 99Food uses 19-digit numbers for stores and orders; they are stored as text so they keep every digit.
* **How orders are found.** Orders come from the order numbers in the financial entries of each store. Orders a store did not accept (refused or cancelled before acceptance) do not appear. An order whose status changes later (completed, cancelled or refunded) is read again: an order still in progress is checked on the next syncs, for up to 7 days (after that the sync log counts the orders kept with their last status), and a refund or cancellation creates a new financial entry that makes the order be read again.
* **Orders 99Food does not return.** If 99Food does not return an order, the sync log says so and the next syncs try again, up to five times. After that the table's run is marked as failed once; the order's amounts are still in Financial Entries.
* **Late financial updates.** Financial entries get their daily payment id and payment date after they are created, and some entries change weeks later (for example, a cancellation), so each sync reads the last 35 days again (records read twice are merged).
* **Today's entries.** If 99Food keeps adding entries to a store's today while the connector reads them, that store's today is left for the next sync, and the sync log says so. Nothing is lost: the next sync reads that whole day again, both its financial entries and its orders.
* **Stores linked later.** A store linked to the application after the first sync gets its own history on its next sync: financial data from the Start Date (up to three months) and orders from the Order Details Backfill.
* **Stores unlinked or removed from Store IDs.** Their orders still waiting to be read again are no longer followed (the sync log counts them) and keep the values already loaded; the other stores are not affected. If the store comes back, its financial data is read again from the Start Date (up to three months) and its orders continue from where they stopped, so the time it was away is covered as long as it is within the three months 99Food keeps (the sync log warns otherwise). After a long absence, its orders are read from the oldest day 99Food still has (up to 88 days), not from the Order Details Backfill; each sync reads at most Max Orders per Sync of them, and the sync log warns if the Orders table falls behind.
* **Long pauses.** 99Food only keeps three months of financial data. If the source does not sync for longer than that, the period in between can no longer be read, and the sync log names it. Keep the source syncing at least monthly.
* **Empty menus.** If 99Food answers a store's menu with no menus, categories, items or modifier groups at all, the menu tables are not updated in that sync (instead of erasing that store's menu), and the sync log says so.
* **Local time.** `business_date_time` and `cancel_date_time` are in the store's local time, as 99Food sends them; `business_at` is the same moment in UTC.
* **Personal data.** The Orders table includes the customer's name, document and delivery address as sent by 99Food (`receive_address`). Handle it according to your data protection policies.

## Fields by stream

Below you'll find all available data streams from 99Food and their corresponding fields:

> [accordion] Stores
>
> Stream `stores`. Full table; key `shop_id`.
>
> * `shop_id` - Unique identifier of the store in 99Food (64-bit number, kept as text)
> * `app_shop_id` - Identifier of the store in the integrator's system (the Store ID used by this connector)
> * `shop_name` - Name of the store
> * `bound_flag` - Whether the store is linked to the application: 1 linked, 0 not linked
> * `shop_phone` - Phones of the store (JSON array of objects with type, phone and callingCode)

> [accordion] Store Details
>
> Stream `store_details`. Full table; key `shop_id`.
>
> * `shop_id` - Unique identifier of the store in 99Food (64-bit number, kept as text)
> * `app_shop_id` - Identifier of the store in the integrator's system
> * `name` - Name of the store displayed to customers
> * `logo_img` - URL of the store's logo image
> * `head_img` - URL of the main image shown to customers browsing the store
> * `announce` - Top address line of the store location
> * `addr` - Address of the store
> * `poi_name` - Address of the store as mapped to a point of interest
> * `lat` - Latitude of the store's address
> * `lng` - Longitude of the store's address
> * `biz_status` - Business status of the store: 1 online, 2 closed
> * `sub_biz_status` - Detailed real-time status: 1 opened, 2 paused, 3 closed, 4 disconnected, 5 closed for the day, 6 blocked, 7 closed by the system
> * `auto_switch` - How the store goes online: 1 manually, 2 automatically
> * `promise_produce_time` - Average preparation time configured by the store, in seconds
> * `shop_phone` - Phones of the store (JSON array)
> * `biz_day_time` - Days and hours when the store opens (JSON array)
> * `main_categories` - Main, second and third categories of the store (JSON object)
> * `shop_front_photo` - URL of the photo of the store front
> * `shop_surrounding_photo` - URL of the photo of the store surroundings
> * `building_entrance_photo` - URL of the photo of the building entrance
> * `busy_mode_info` - Busy-mode configuration: busy state, duration and extra preparation minutes (JSON object)
> * `store_availability_status` - Whether the store can take orders: 1 available, 2 unavailable
> * `store_unavailable_reason` - Reason why the store is unavailable
> * `store_unavailable_end_at` - Expected end of the store's unavailability (UTC)

> [accordion] Menus
>
> Stream `menus`. Full table; key `app_shop_id`, `app_menu_id`.
>
> * `app_shop_id` - Identifier of the store in the integrator's system
> * `app_menu_id` - Identifier of the menu in the integrator's system
> * `menu_name` - Name of the menu
> * `app_category_ids` - Identifiers of the categories available while this menu is active

> [accordion] Menu Categories
>
> Stream `menu_categories`. Full table; key `app_shop_id`, `app_category_id`.
>
> * `app_shop_id` - Identifier of the store in the integrator's system
> * `app_category_id` - Identifier of the category in the integrator's system
> * `category_name` - Name of the category shown to customers
> * `app_item_ids` - Identifiers of the items of the category, in display order
> * `priority` - Display order of the category in the customer app

> [accordion] Menu Items
>
> Stream `menu_items`. Full table; key `app_shop_id`, `app_item_id`.
>
> * `app_shop_id` - Identifier of the store in the integrator's system
> * `app_item_id` - Identifier of the item in the integrator's system
> * `app_external_id` - Free-form field reserved for the restaurant or its POS
> * `item_name` - Name of the item shown to customers
> * `short_desc` - Short description of the item
> * `head_img` - URL of the item's image
> * `sold_info_intl` - Days, hours and special days when the item is sold (JSON array)
> * `price` - Price of the item in cents (smallest currency unit), as sent by 99Food
> * `activity_price` - Promotional price of the item in cents (smallest currency unit), as sent by 99Food
> * `priority` - Display order of the item inside its category
> * `status` - Availability of the item in the customer app: 1 available, 2 unavailable
> * `is_sold_separately` - True when the item can be sold on its own; false when only inside a modifier group
> * `app_modifier_group_ids` - Identifiers of the modifier groups of the item

> [accordion] Menu Modifier Groups
>
> Stream `menu_modifier_groups`. Full table; key `app_shop_id`, `app_modifier_group_id`.
>
> * `app_shop_id` - Identifier of the store in the integrator's system
> * `app_modifier_group_id` - Identifier of the modifier group in the integrator's system
> * `modifier_group_name` - Name of the modifier group shown to customers
> * `app_external_id` - Free-form field reserved for the restaurant or its POS
> * `is_required` - Whether a selection is required: 1 required, 2 optional
> * `quantity_min_permitted` - Minimum quantity the customer must pick (inclusive)
> * `quantity_max_permitted` - Maximum quantity the customer may pick (inclusive)
> * `buy_mode` - 0 single choice; 1 the customer may pick the same item more than once
> * `app_mg_items` - Items of the group with their price in cents inside the group (JSON array of objects)

> [accordion] Financial Entries
>
> Stream `financial_entries`. Incremental by `business_at`; key `app_shop_id`, `order_id`, `order_type`, `business_ts`.
>
> * `app_shop_id` - Identifier of the store in the integrator's system (the Store ID the entry was read for)
> * `shop_id` - Identifier of the store in 99Food
> * `shop_name` - Name of the store
> * `contractor_id` - Identifier of the legal entity of the store
> * `contractor_name` - Name of the legal entity of the store
> * `city_id` - Identifier of the city of the store
> * `city_name` - Name of the city of the store
> * `order_id` - 99Food order id for order entries (types 1, 2, 3, 4, 8, 9); the expense id for non-order entries (type 5)
> * `order_index` - Short order number shown to the store (order entries only)
> * `order_type` - Entry type: 1 order revenue, 2 order refund, 3 partial refund during the sale, 4 after-sale refund, 5 non-order expense (e.g. ads), 8 meal loss deduction, 9 item exchange adjustment
> * `delivery_type` - 0 no delivery, 1 platform delivery, 2 store delivery (order entries only)
> * `business_ts` - When the entry happened, as Unix seconds
> * `business_at` - When the entry happened (UTC); used as the incremental replication key
> * `business_date_time` - When the entry happened, in the store's local time as sent by 99Food (YYYY-MM-DDTHH:MM:SS, no time zone)
> * `meal_original_amount` - Original price of the meal before discounts, in cents
> * `shop_activity_outcome` - Store's cost of item discounts, in cents
> * `shop_activity_subsidy` - Platform subsidy to the store for item discounts, in cents
> * `shop_delivery_amount` - Delivery fee collected by the store in self-delivery, in cents
> * `shop_pre_tips` - Tip paid by the customer to the store, in cents
> * `free_delivery_outcome` - Store's cost of free-delivery campaigns, in cents
> * `free_delivery_subsidy` - Platform subsidy to the store for free-delivery campaigns, in cents
> * `commission_base_amount` - Base amount of the commission, in cents
> * `commission_rate` - Commission rate in hundredths of a percent (3500 = 35%)
> * `commission_amount` - Commission charged by the platform, in cents
> * `commission_subsidy_amount` - Platform subsidy to the store on the commission, in cents
> * `b2p_delivery_amount` - Logistics fee charged by the platform to the store, in cents
> * `pay_commission_amount` - Payment processing fee charged to the store, in cents
> * `min_value_difference_amount` - Amount paid by the customer to reach the minimum order value, in cents
> * `order_amount` - Final order amount of the entry, in cents
> * `payment_method` - 0 unspecified, 1 online, 2 offline, -1 refund
> * `payment_channel` - Payment channel code (e.g. 150 credit card, 153 cash, 212/280 PIX)
> * `payment_method_detail` - Detailed payment method code
> * `card_brand` - Card brand (VISA, MASTERCARD...) when paid by card
> * `cancel_ts` - When the order was cancelled, as Unix seconds (0 when not cancelled)
> * `cancel_date_time` - When the order was cancelled, in the store's local time as sent by 99Food
> * `cancel_reason` - Cancellation reason code (0 none; 1 customer; 101 store; 202 no rider; 301 customer service...)
> * `cash_balance` - Cash collected by the store for cash orders, in cents
> * `meal_voucher_amount` - Amount paid with meal vouchers, in cents
> * `settlement_amount` - Final amount settled to the store for this entry, in cents
> * `expect_settle_date` - Date the amount is scheduled to be paid to the store
> * `day_payment_id` - Identifier of the daily settlement that includes this entry (filled in once settled)
> * `meal_loss_deduct_amount` - Deduction for a cancellation the store is liable for, in cents (type 8)
> * `vat_amount` - Value-added tax on platform commissions, in cents
> * `merchant_appeal_amount` - Compensation after a successful appeal by the store, in cents (type 5)
> * `monthly_service_price` - Monthly fee charged to grocery stores, in cents (type 5)
> * `gmv` - GMV of the monthly-fee period of grocery stores, in cents (type 5)
> * `monthly_service_base_price` - Monthly-fee threshold of grocery stores, in cents (type 5)
> * `monthly_service_calculation_cycle` - Monthly-fee period of grocery stores (YYYY-MM-DD\~YYYY-MM-DD)
> * `raw_payload` - The entry exactly as sent by 99Food (JSON object)

> [accordion] Weekly Settlements
>
> Stream `weekly_settlements`. Incremental by `settle_end_date`; key `app_shop_id`, `week_payment_id`.
>
> * `app_shop_id` - Identifier of the store in the integrator's system (the Store ID the payout was read for)
> * `week_payment_id` - Unique identifier of the weekly payment
> * `shop_id` - Identifier of the store in 99Food
> * `withdraw_date` - Date the payout was actually made
> * `withdraw_amount` - Amount of this payout, in cents
> * `liability` - Entity responsible for the payment
> * `settle_start_date` - First day of the settled period
> * `settle_end_date` - Last day of the settled period; used as the incremental replication key
> * `currency` - Currency code (BRL)
> * `day_payment_id_list` - Identifiers of the daily settlements included in this payout
> * `day_payment_amount_list` - Amounts of the daily settlements included in this payout, in cents (JSON array)
> * `payee_cnpj` - CNPJ that received the payout
> * `payer_cnpj` - CNPJ of 99Food that made the payout
> * `cnpj_withdraw_amount` - Total paid to the receiving CNPJ across all its stores, in cents
> * `cerc_amount` - Amount withheld and paid to a third party after receivables were sold through CERC, in cents
> * `raw_payload` - The payout exactly as sent by 99Food (JSON object)

> [accordion] Orders
>
> Stream `orders`. Incremental by `last_financial_entry_at`; key `order_id`.
>
> * `order_id` - Unique 99Food order number (19 digits, kept as text)
> * `app_shop_id` - Identifier of the store in the integrator's system
> * `shop_id` - Identifier of the store in 99Food
> * `status` - Current status: 100 created, 200 accepted, 400 picked up, 500 courier arrived, 600 completed, 9xx cancelled (see the 99Food status table)
> * `shop_accept_status` - Acceptance status of the order by the store
> * `before_status` - Status before the current one
> * `order_index` - Short order number used between the store and the courier
> * `remark` - Customer's instructions for the order
> * `city_id` - Identifier of the city in 99Food
> * `country` - Country of the order
> * `timezone` - Time zone of the order
> * `pay_type` - Legacy payment method code (see pay\_channel)
> * `pay_method` - 1 online payment, 2 offline payment
> * `pay_channel` - Payment channel code (110 coupon, 150 card, 153 cash, 212/280 PIX...)
> * `change_for` - Cash the customer will pay with, for change, in cents
> * `delivery_type` - 0 customer pickup, 1 delivery by 99Food, 2 delivery by the store
> * `fulfillment_mode` - 0 delivery, 1 self pickup
> * `expected_cook_eta` - Time by which the meal should be ready, as sent by 99Food
> * `expected_arrived_eta` - Estimated delivery time, as sent by 99Food
> * `created_at` - When the order was placed (UTC)
> * `paid_at` - When the order was paid (UTC)
> * `shop_confirmed_at` - When the store confirmed the order (UTC)
> * `completed_at` - When the order was completed (UTC)
> * `cancelled_at` - When the order was cancelled (UTC)
> * `order_price` - Sum of the item prices without promotions or delivery, in cents
> * `items_discount` - Promotions on items perceived by the customer, in cents
> * `delivery_price` - Delivery fee charged after delivery promotions, in cents
> * `delivery_discount` - Delivery promotions perceived by the customer, in cents
> * `store_charged_delivery_price` - Original delivery fee before promotions, in cents
> * `real_price` - Total the store receives (with delivery) without the promotions subsidised by 99Food, in cents
> * `real_pay_price` - Total paid by the customer (with delivery), in cents
> * `refund_price` - Total refunded on the order, in cents
> * `shop_paid_money` - Cash the courier pays the store for cash orders, in cents
> * `customer_need_paying_money` - Amount the customer needs to pay, in cents
> * `service_price` - Service fee charged to the customer, in cents
> * `meal_top_up_price` - Fee charged to reach the store's minimum order value, in cents
> * `in_sale_refund_to_c_fee` - Amount under-billed to the store after items were cancelled during the sale, in cents
> * `currency` - Currency of the prices, when sent
> * `logistics_cost` - Delivery cost charged by 99Food to the store for platform delivery, in cents
> * `need_cutlery` - Whether the customer asked for cutlery
> * `c_cancel_preference` - What the customer wants when an item is out of stock
> * `pickup_code` - Legacy 4-digit handover code
> * `handover_code` - 4-digit code used between the store and the courier
> * `takeaway_code` - 4-digit code used between the store and the customer in self pickup
> * `price` - Every price field of the order as sent by 99Food, in cents (JSON object)
> * `shop` - Store information of the order (JSON object)
> * `receive_address` - Customer and delivery address as sent by 99Food, including personal data (JSON object)
> * `promotions` - Promotions applied to the order (JSON array)
> * `shopper_info` - Shopper of grocery orders (JSON object)
> * `items_count` - Number of item lines in the order (see the order\_items table)
> * `last_financial_entry_at` - Latest financial entry that pointed to this order (UTC); used as the incremental replication key

> [accordion] Order Items
>
> Stream `order_items`. Incremental by `last_financial_entry_at`; key `order_id`, `line_number`.
>
> * `order_id` - 99Food order number the line belongs to
> * `line_number` - Position of the line in the order, starting at 1
> * `app_shop_id` - Identifier of the store in the integrator's system
> * `app_item_id` - Identifier of the item in the integrator's system
> * `item_id` - Identifier of the item in 99Food, when sent
> * `mdu_id` - Unique id of the item with its selected quantity and options
> * `app_external_id` - Free-form field reserved for the restaurant or its POS
> * `name` - Item name shown in the menu
> * `sales_type` - How the item is sold: Weight or Unit
> * `weight` - Total weight when sold by weight
> * `weight_unit` - Weight unit when sold by weight (Gram)
> * `amount` - Quantity of the item
> * `submit_refund_amount` - Quantity refunded (amount minus this is the quantity left in the order)
> * `sku_price` - Unit price of the item, in cents
> * `total_price` - Total price of the line without promotions, in cents
> * `real_price` - Amount actually paid by the customer for the line, in cents
> * `promo_type` - Main promotion type applied to the line
> * `promotion_detail` - Summary of the promotions of the line (JSON)
> * `promo_list` - Each promotion applied to the line (JSON array)
> * `sub_item_list` - Options chosen for the line (modifier items), with their prices in cents (JSON array)
> * `remark` - Customer's note for this line (plain text; a JSON array when 99Food sends a list)
> * `last_financial_entry_at` - Replication key copied from the order (UTC)


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