​

Before you start

• You need your own 99Food application. The App ID and App Secret come from an application created in the 99Food developer portal 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

​

1. Add account access

• 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.

​

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.

​

2. Select streams

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

​

3. Configure data streams

• 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.

​

4. Configure data source

• 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.

​

5. Check your new source

​

Streams and Fields

​

Available streams

​

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