The connector only reads data. It never creates, changes or cancels anything in Takeat.
Configuring Takeat as a Source
In the Sources tab, click on the “Add source” button located on the top right of your screen. Then, select the Takeat option from the list of connectors. Click Next and you’ll be prompted to add your access.1. Add account access
The connector uses an API key created by the restaurant in Takeat’s AI Builders portal. To create it:- Log in to AI Builders with the restaurant account. For a network of stores, log in with the network owner account (Dono de multilojas) and choose the stores the key can read.
- Create an API key, give it a name and choose the Production environment. Its value starts with
tk_live_. - Grant the read permissions of the data you want:
table-sessions:read(table sessions, payments and orders),payment-methods:read,financial:read,brands:read,nfe-received:read,products:read,complements:read,inputs:readandintermediaries:read. - Copy the whole key. Takeat shows it only once.
- API Key: the key copied above. The connector exchanges it for short-lived access tokens on every run.
- Start Date: the earliest date to extract: table sessions started, financial entries due and received NF-e issued on or after this date. We recommend a recent date (for example, the beginning of the current month or year): see the request limit below.
- Restaurant IDs (advanced): the ids of the Takeat stores to extract. Leave it empty to extract every store the key gives access to. It is only needed for partner keys that cannot list their stores.
- Daily Request Limit (advanced): (Default: 500) how many requests per day Takeat allows this key. Each run only uses what is left of the day. Lower it to leave part of the quota to other integrations that use the same key.
- Lookback Days (advanced): (Default: 3) how many days before the last extracted point every run reads again, to pick up table sessions changed after they started (payments, closing, cancellations).
A key of the Test environment (
tk_test_) is not a sandbox: it reads the restaurant’s real data and has the same limits. Use the Production key.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.
Table Session Payments and Table Session Orders come from the same request as Table Sessions, so selecting them costs no extra requests. Each selected stream needs its permission on the API key: the run stops before extracting anything and lists the missing permissions otherwise.
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: Table Sessions, Table Session Payments, Table Session Orders, Financial Entries, Financial Entry Items and Received NF-e support INCREMENTAL, and that is the recommended type for them. The catalog, stock, brands, payment methods and restaurants streams are FULL_TABLE: they are small and read in full on every run, so your tables always show their current state. Read more about Sync Types here.
4. Configure data source
Describe your data source for easy identification within your organization, not exceeding 140 characters. To define your Trigger, consider how often you want data to be extracted from this source. Because of Takeat’s request limit, schedule it once or twice a day (once a day is usually enough for reconciliation). Each run keeps a little room for one more run on the same day, but while a long history is still loading, the first run of the day uses most of the quota. 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.
- Do not enable an Additional Full Sync for this source. A full sync reads all table sessions, financial entries and NF-e since the Start Date before writing them; with a long history it does not fit in Takeat’s daily request limit and the run stops without writing anything. The same applies to a full sync triggered manually.
5. Check your new source
You can view your new source on the Sources page. If needed, manually trigger the source extraction by clicking on the arrow button. Once executed, your data will appear in your Catalog.Streams and Fields
Available streams
The table below lists every stream, its slug (the exact identifier to pass when creating the source via API) and a short description.Fields by stream
Sales and payments
Table Sessions
Table Sessions
One row per table session (comanda): dine-in, counter, totem and delivery, open and closed, with totals, discounts, service fee, fiscal note (NFC-e) and status timings.Table:
table_sessions · Primary key: id · Sync: Incremental (start_time)Table Session Payments
Table Session Payments
One row per payment of a table session: amount, change, payment method, the amount expected after the method’s fees and the expected settlement date. Read from the same response as Table Sessions, with no extra request.Table:
table_session_payments · Primary key: id · Sync: Incremental (session_start_time)Table Session Orders
Table Session Orders
One row per order line of a table session: product, quantity, price, channel and cancellation. Read from the same response as Table Sessions, with no extra request.Table:
table_session_orders · Primary key: id · Sync: Incremental (session_start_time)Payment Methods
Payment Methods
Payment methods enabled in each store.Table:
payment_methods · Primary key: restaurant_id, id · Sync: Full tableFinancial
Financial Entries
Financial Entries
Accounts payable and receivable (Financeiro > Lançamentos), paid and open, with supplier, bank account, payment method and linked NF-e. Recent due dates and open entries are read on every run; older months in turn (see Implementation Notes).Table:
cash_flows · Primary key: restaurant_id, id · Sync: Incremental (due_date)Financial Entry Items
Financial Entry Items
Items of the financial entries that group several items (purchase invoices and titles).Table:
cash_flow_items · Primary key: restaurant_id, id · Sync: Incremental (due_date)Received NF-e
Received NF-e
NF-e issued to the store by suppliers, authorized and not canceled, with issuer, total and manifestation. Recent months are read on every run; older months in turn.Table:
received_nfes · Primary key: restaurant_id, id · Sync: Incremental (issued_at)Stores and brands
Restaurants
Restaurants
The stores (restaurants) extracted by this source. Every other table has a
restaurant_id column to join with it.Table: restaurants · Primary key: id · Sync: Full tableBrands
Brands
Brands of each store, with their trade name and CNPJ, active and inactive.Table:
brands · Primary key: restaurant_id, id · Sync: Full tableCatalog and stock
Products
Products
Products of the catalog with prices, availability, fiscal data and category.Table:
products · Primary key: restaurant_id, id · Sync: Full tableProduct Categories
Product Categories
Product categories with their availability per channel.Table:
product_categories · Primary key: restaurant_id, id · Sync: Full tableComplements
Complements
Complements (add-ons) with prices and availability, and the categories that offer them.Table:
complements · Primary key: restaurant_id, id · Sync: Full tableComplement Categories
Complement Categories
Complement categories (the questions shown with a product) and their rules.Table:
complement_categories · Primary key: restaurant_id, id · Sync: Full tableStock Inputs
Stock Inputs
Inputs (raw materials) registered in stock control, with balance, cost and restock levels.Table:
inventory_inputs · Primary key: restaurant_id, id · Sync: Full tableStock Intermediate Products
Stock Intermediate Products
Intermediate products prepared from inputs, with balance, cost and restock levels.Table:
inventory_intermediaries · Primary key: restaurant_id, id · Sync: Full tableImplementation Notes
Data Quality Considerations
- Every table has a
restaurant_idcolumn with the Takeat store the row belongs to; join it torestaurants.id. - All dates and times are in UTC. Subtract 3 hours for Brasília time.
- Fees of a payment:
payment_valueminuspredicted_received_value.predicted_received_dateis the settlement day Takeat expects from the payment method’s settings, not a confirmation from the acquirer. Takeat sends this day with a time of day it does not document: compare one value with the Takeat manager before deciding whether to take its day in Brasília time or in UTC. - Cash payments:
payment_valueis what counts as revenue (change already deducted),original_valueis what the customer handed over andchangeis the change given back. - In
table_sessions,total_priceandtotal_service_pricealready include the session discount (old_total_priceis the value before it). The values oftable_session_ordersdo not include the session discount. - Canceled order lines keep their row with
canceled_atandcancel_reason. - Rows with
removed_atfilled were read before and are no longer in Takeat (a reversed payment, a deleted financial entry, a canceled NF-e); only their key columns (and a date in the incremental column) are kept. Filterremoved_at IS NULLto get the current data. - Each run reads again the table sessions started in the last Lookback Days before the previous run. Sessions still open after that are checked one by one until they close, for up to 30 days. Once a week the last 30 days of sessions are read again: a change to an already closed session after the lookback (for example, a payment reversed days later) reaches your tables at that weekly re-read, not before.
- Financial entries: every run reads every entry due in the last 7 and the next 7 days, and every entry still open (due from 92 days before the Start Date to a year ahead). When an open entry is paid, its due date is read again in the same run. The current and previous month are read in full once a day; other months at most once a week, in turn. An edit to an old entry that was already paid (or a deletion) reaches your tables when its month is read again, within about a week once the history is loaded. If a paid entry’s due date is moved to another month, it can show as removed until that month is read.
- Received NF-e: the previous and current month are read on every run, older months at most once a week, in turn.
- In
cash_flows, thevalueof an invoice or title is already the sum of its items incash_flow_items: do not add both. For cost center analysis, use the rows withcounts_for_resulttrue. - Fields that Takeat sends and that have no column of their own are kept in
additional_fields(JSON), so nothing is lost when Takeat adds new fields.
API Limits & Performance
- Takeat allows 10 requests per minute and 500 per day per API key. The connector waits 6.5 seconds between requests, so a run with a few hundred requests takes 30 to 50 minutes; once the history is loaded, a daily run usually needs well under 100 requests per store.
- Each run first reads the FULL_TABLE streams (catalog, stock, brands, payment methods) in full. Then table sessions get what is left after keeping the recurring part of financial entries and NF-e (recent days, open entries, recent months) and room for one more run on the same day.
- With several stores, the stores take turns: the ones most behind go first, and each gets enough for real progress instead of an even split that is too small for any. With many stores and a long history, a store’s financial entries or NF-e may be updated every other run while the history loads; the sync log warns when a store waits 3 runs in a row. If a store’s table sessions make no progress for 3 runs in a row the log warns, and at 5 runs the run fails, so the problem does not go unnoticed.
- Table sessions are read 100 per request; a store with 300 sessions a day needs about 21 requests per week of history, so a year of history takes several days to load.
- Product technical sheets, NF-e details, the loyalty club clients and the published menu are not extracted.
Troubleshooting
Skills for agents
Download Takeat skills file
Takeat connector documentation as plain markdown, for use in AI agent contexts.