Everything you need to master the platform — guides, step-by-step and answers.
Search for the articles here or browse the categories below.
Browse by topic
Find guides, tutorials, and answers organised by category.
Getting Started
Platform overview, login, profile, 2FA, interface tour, core concepts and onboarding with the Maestro Brain.
Browse
Inboxes & Channels
WhatsApp Web and Cloud, Coexistence, groups/communities Hub, templates/flows/calls, website, email, social, voice and API.
Browse
Conversations & Support
Conversation view, replies, notes, assignment, status, priority, labels, macros, canned responses, search, filters and SLA.
Browse
Contacts & CRM
Contacts, import, segments, attributes, companies, pipelines/kanban/deals and orders registry.
Browse
Catalog & Commerce
Native catalog, sync and WhatsApp Business Catalog, sending products/orders in the conversation and e-commerce lifecycle.
Browse
Payments
Connect a gateway (Asaas/Mercado Pago), create charges (PIX/boleto/card), subscriptions, discounts, paid scheduling and reports.
Browse
Calendar & Scheduling
Connect Google Calendar, event types, availability, public booking page, reschedule/cancel, Meet and .ics.
Browse
Tasks
Lists, board and calendar, subtasks, dependencies, recurrence, reminders, SLA, templates and the in-conversation panel.
Browse
Follow-ups & Cadences
Sequences, steps, channels, composition, enrollment (manual/automation/event/inactivity/AI), funnel, exit and human-in-the-loop AI.
Browse
Automation & Flows
Automation rules, macros, Flow Builder, smart routing, bots and Captain.
Browse
Maestro AI & Account Brain
What Maestro is, voice onboarding, generative copilot (propose→confirm→execute), departments, risk, insights and per-module tools.
Browse
Growth & Marketing Studio
Page/Form Builder, AI Studio, social publishing, Ads/CTWA/leadgen, launches, launch groups, social automation and Collaboration Network.
Browse
Contracts & E-signature
Issuing companies, A1 certificate, templates, variables, auto-fill, internal/external signing, public page and validator.
Browse
Sales & Gamification
Sales management, books of business, goals, goal-over-goal, gamification, leaderboard, rewards, commissions, wallboard and lead score.
Browse
Media
Media library, folders, trash, storage meter and reusing files across any channel.
Browse
Internal Chat
Channels, direct messages, announcements and sharing entities (conversations, contacts, deals) as cards.
Browse
Reports & Analytics
Overview, conversations, agents, teams, labels, inbox, CSAT, SLA and per-module reports.
Browse
Campaigns
Website campaigns, WhatsApp campaigns, HSM templates and variables.
Browse
Administration & Settings
Account, agents, teams, roles and governance (RBAC), business hours, labels, attributes, integrations, audit, whitelabel, scripts and notifications.
Browse
API & Developers
REST API, tokens, webhooks, Custom Scripts SDK and per-module events.
Browse
FAQ & Troubleshooting
Frequently asked questions, common errors (WhatsApp disconnected, pairing, failed payment), limits and anti-ban best practices.
Browse
Popular articles
What other people are reading right now.
Manage payment plans and offers
Overview The Payments module provides two reusable catalogs: - Plans store a connection, amount, currency and cycle for new subscriptions. - Offers store price, payment method, type and optional links to a connection and product. The Offers screen is administrative. It never accepts an offer or creates a charge without a contact or purchase context. Prerequisites - Payments must be enabled for the account. - Have at least one active Asaas or Mercado Pago connection to create plans. - To link an offer, create the product in Catalog first. - Permanent deletion requires payment-administration permission. Step by step 1. Open Payments in the sidebar. 2. Go to Plans or Offers. 3. Use search, filters and sorting to find records. The page and filters remain in the URL. 4. Click New plan or New offer, complete the fields and save. 5. Archive a record to remove it from use. Open Archived to restore it or, with the required permission, permanently delete it. 6. For multiple rows, select records on the page and use the bulk-action bar. If a row fails, review the displayed IDs and fix only those rows. 7. When creating a subscription, select the optional plan. The screen fills and locks connection, amount, currency, and cycle so the subscription matches the template. 8. Use Export CSV to download the current filtered result or, when records are selected, only the selected records, including selections kept while moving between pages. Settings & options Plans A plan is a local template; it does not claim to already exist as a gateway entity. Actual recurrence is created at the gateway only when a subscription starts. Currency must match the connection settlement currency, and displayed cycles follow its capabilities; for example, every-two-month billing appears only when the gateway supports it. Offers Choose order bump, upsell or downsell. The connection may use the account default and the product is optional. Archiving an offer deactivates it; restoring it keeps it inactive until it is reviewed and enabled again. Use cases - Reuse one membership price across several subscriptions. - Offer setup, priority support or an add-on during checkout. - Keep seasonal offers inactive without losing their configuration. - Separate offers by product, connection, type or status. Tips, limits & best practices - Confirm the connection settlement currency before publishing prices. - Archive before permanent deletion. Permanent deletion cannot be undone. - Restoring an offer does not activate it automatically; review price, product and connection first. - A bulk action is processed record by record. A partial result is expected when a row violates a lifecycle rule. Troubleshooting - Every-two-month billing is missing: the selected connection does not advertise that capability. - A payment method is missing: the selected connection does not support it. - I cannot delete a record: archive it first and confirm your role allows permanent deletion. - The list is empty after filtering: use Clear filters; the state can also be removed from the URL. - A restored offer is inactive: this is the safe behavior. Edit and enable it after review. See also - Create charges and send them in a conversation - Subscriptions and plans
🧠 Maestro AI & Account BrainDaily Help Center sync into the bot's knowledge base
Overview There are two different integrations between the Help Center and Maestro. Their names sound alike, but their scope and speed are very different — mixing them up is the most common cause of "I published the article and the bot doesn't know it": | | Per-bot article picker | Daily account-level sync | |---|---|---| | What gets in | only the articles/categories you tick | everything published, across all portals | | Who uses it | that bot only | every bot in the account (shared base) | | When it updates | instantly — on saving the selection and on every edit/publish of the article | once a day, automatically | | Where you set it up | knowledge tab in the bot's configuration | nothing to set up: it is automatic | The first one always worked instantly. The second — the one that takes the whole portal into the account's shared base — had no automatic trigger: it only ran if an installation administrator fired it by hand. From this version on it runs by itself, every day. Each published article becomes a document in the account base under the path help-center/{portal}/{category}/{article} — so the bot answers with the official content and can cite which article the answer came from. Articles with no category land in uncategorized. Prerequisites - An account with Maestro enabled and at least one active bot. The daily sweep skips accounts with no active bot — there would be nobody to hand the knowledge to. - A Help Center portal with articles in the published status. - An embeddings provider with a valid key and credits — this is the same indexing used by the Account Brain's knowledge base. - The sync must be enabled on the installation (a deployment switch under the installation administrator's control). If it is off, no account syncs. Step by step 1. Write and publish your articles in the portal, as usual. Drafts and archived articles do not count. 2. Do nothing else. The sweep runs automatically every day at 05:10 UTC (02:10 in Brasília time). It is not triggered when the service restarts: it waits for the scheduled time. 3. Check it the next day: ask the bot something that only exists in that article. The answer should carry the published content and point to its origin under help-center/…. 4. Need it to count right now, without waiting for the next day? Two ways out: - tick the article (or the whole category) in the bot's knowledge tab — that selection applies immediately and stays in sync on every edit; - or ask an installation administrator to trigger the account sync on demand. Settings & options - Daily cadence, at 05:10 UTC. The odd time is deliberate: Maestro's other automatic routines run on round hours, and the Brain's structure mapping runs 55 minutes earlier — so reading the articles never competes with the previous routine over the same account. - Scope: every portal in the account, every published article. The category becomes a "folder" in the document path. - Indexed content: the article's title plus its body. Subheadings (##, ###) drive how the text is split into passages — each passage carries the section it came from, which improves citations. - Read-only: the sync never edits, publishes, unpublishes or deletes an article. It only reads the portal and writes into the Maestro base. - One run per account, per day: if the previous day's sync is still running when the next one starts, the new one is dropped. There are never two writing to the same base at once. - Atomic replacement: content is indexed before the base is touched, and the swap happens in a single transaction. A failure halfway through never empties what was already indexed. - Error isolation: a broken article, page or portal is counted and the sweep carries on with the rest — one bad item does not sink the whole sync. - Pagination guard: reading each portal is capped and stops on its own when articles start repeating, preventing an endless read. Use cases - Getting the bot to answer with the official published policy, citing the article, instead of a hand-pasted and outdated copy. - Keeping a single source of truth: the team edits the portal, and every bot inherits it. - Accounts with many articles: using the whole portal without ticking item by item. - New bots start out knowing — the base belongs to the account, not to one bot. - Trilingual portals: whatever is published in each language goes into the base. Tips, limits & best practices - Drafts and archived articles do not get in. An article with an empty body is skipped too (and whatever was already indexed is preserved). - Unpublishing does not remove the article from the shared base in the daily sweep: it adds and updates, it does not delete documents for articles that went offline. If a piece of content must disappear from answers immediately, use the per-bot picker (which removes it on unpublish) or ask an administrator to remove that source. - Cost: every run re-indexes the published articles, and indexing costs money per account. That is why the cadence is daily: it is the cheapest steady state that keeps staleness within 24 hours. Running hourly would multiply that cost by 24 to watch content that rarely changes by the hour. - A window of up to 24 hours: urgent changes should go through the per-bot picker, which applies immediately. - A good article makes a good answer: clear titles, well-divided sections and up-to-date content produce better citations. Stale content produces stale answers. Troubleshooting - "I published yesterday and the bot doesn't know it": confirm the article is published, that the account has at least one active bot, and that the embeddings provider has credits. If the article was published after 05:10 UTC, it only gets in on the following sweep. - "Nothing syncs, in any account": the sync is most likely disabled on the installation. Talk to the installation administrator. - "It synced, but the bot doesn't use it": the bot must be allowed to query the knowledge base. Review the tools enabled for it. - "An old article still shows up in answers": that is the limit described above — unpublishing does not delete it from the shared base. Use the per-bot picker or ask for the source removal. - "Could not index" / embeddings unavailable: no embeddings provider has a valid key and credits. Check the primary provider's credits or connect an alternative key under Integrations — same cause (and same fix) as the knowledge base. See also - Knowledge base and business map (ontology) of the Brain - Where each Robô is used: the account's surfaces - Maestro tools per module and how to enable them - What is Maestro AI and the Account Brain
🧠 Maestro AI & Account BrainDeepSeek as a model provider for your bot
Overview DeepSeek is a language-model provider your bot can use as its main model or as a fallback model, in the same place where you pick OpenAI, Anthropic, Google, Groq and the rest. Access is native: the platform talks straight to api.deepseek.com. That differs from using the same model through OpenRouter — with native access, usage is billed to your DeepSeek account, with your key, with no middleman. | Model | Profile | |---|---| | DeepSeek V4 Pro | The most capable of the family — for reasoning and complex tasks. | | DeepSeek V4 Flash | The fastest and cheapest — for volume and short replies. | Prerequisites - Maestro enabled and a configured bot. - A DeepSeek API key (create one at platform.deepseek.com/api_keys). - Administrator permission to configure keys. Step by step Pick one of the three places for the key — the bot looks them up in this order: 1. This bot only — in the bot's configuration, API keys (per provider) section, DeepSeek row: paste the key and hit Test to confirm before saving. 2. For the whole account — under Settings → Integrations → DeepSeek, enter the key. Every bot in the account can then use it (as long as that bot has account-key usage turned on). 3. For the installation — the operator sets the key in the super admin panel. It applies as a last resort for every account. Once the key is saved: 4. Go back to the bot's configuration and open the Model picker. 5. Choose DeepSeek V4 Pro or DeepSeek V4 Flash as the main model, or add one of them to the fallback chain. 6. Save. Settings & options The key lookup order | Order | Source | When to use it | |---|---|---| | 1st | The bot's own key | A specific bot with separate cost. | | 2nd | The account key (Integrations) | The default for most operations. | | 3rd | The installation key | Set by the operator; covers anyone without their own. | The bot's key always wins. The two global sources only apply if the installation allows it and the bot has that option on — the same rule as every other provider. Live model list With a key configured, the platform reads the model list straight from DeepSeek, so a newly released model shows up without an update. The listing requires the key — there is no anonymous lookup. If the lookup fails, the picker falls back to the curated list above and is never empty. Native vs through OpenRouter The same model may appear twice in the picker: - deepseek:… — native access, billed to your DeepSeek account. - openrouter:deepseek/… — the same model through OpenRouter, billed to your OpenRouter account. This is not a duplicate: they are different routes and different invoices. Pick native if you have a DeepSeek account. Use cases - Cost at volume — DeepSeek V4 Flash on high-volume bots with short replies. - Heavier reasoning — DeepSeek V4 Pro on bots that analyse or decide. - Fallback for another provider — put a DeepSeek model in the chain so service does not stop when the main provider is unavailable or out of credit. Tips, limits & best practices - Test the key in the form before saving. An invalid key shows up immediately. - When building the fallback chain, avoid repeating the same provider back to back: if the outage is account-level (out of credit), the second attempt knocks on the same closed door. Alternate providers. - Usage is billed to your DeepSeek account — watch the balance there. - The key is write-only: once saved, the interface only shows that one exists, never its value. - Switching models does not clear any other bot setting. Troubleshooting - "DeepSeek does not appear in the model picker" — there is no key at any of the three levels, or the bot has global-key usage turned off. - "The key was rejected in the test" — issue a new one at platform.deepseek.com/api_keys and check for a leading or trailing space. - "The model list came back empty" — the DeepSeek lookup failed; the picker shows the curated list and you can still choose normally. - "The bot fell back to another provider constantly" — check the DeepSeek account balance. - "I chose DeepSeek and the charge landed on OpenRouter" — you selected the openrouter:deepseek/… variant; switch to the one starting with deepseek:. See also - What Maestro AI and the Account Brain are - Portable templates: save, duplicate, share and migrate a bot - Maestro tools by module - Where each bot is used
🧠 Maestro AI & Account BrainReply formatting: adapt to the channel, or deliver raw markdown
Overview The model always writes in markdown — that is the format it was trained to structure text in. The catch is that every channel understands markdown differently: WhatsApp uses *asterisks* for bold, the web widget renders full markdown, and some channels format nothing at all. Reply formatting decides what happens between what the model wrote and what the contact reads: - Adapt to the channel — translates formatting into the destination channel's dialect. Bold becomes *like this* on WhatsApp, and plain text where there is no support. - Do not format — delivers the raw markdown exactly as the model wrote it. Prerequisites - A Robô already created and configured. - Account administrator access to edit the Robô. Step by step 1. Open Settings → Robôs and edit the Robô. 2. Go to the Delivery section. 3. Under Reply formatting, pick Adapt to the channel or Do not format. 4. Save. The change applies to the next replies; messages already sent are not rewritten. Settings & options | Option | What it does | |---|---| | Adapt to the channel | Converts formatting into what the destination channel understands | | Do not format | Sends the model's markdown untouched | The choice belongs to the Robô, not to the channel: one Robô serving both WhatsApp and the widget adapts for both from a single setting. Use cases - WhatsApp support: use Adapt to the channel. Without it, a markdown **bold** reaches the contact as four literal asterisks in the middle of the sentence. - An integration consuming the reply over the API: use Do not format. The system on the other side usually prefers the original markdown so it can render it its own way. - A channel that already renders markdown: either works; adapting is the safe default. Tips, limits & best practices - When in doubt, Adapt to the channel. It is what the contact expects to see. - Do not format does not mean "plain text": it means markdown intact. If the channel does not render markdown, the contact sees the symbols. - This controls formatting only. It does not change the content, the language or the reply length. Troubleshooting The contact is seeing ** or ## inside the text. The Robô is on Do not format in a channel that does not render markdown. Switch it to Adapt to the channel. The reply arrives with no emphasis at all. The destination channel supports no formatting — the adapt mode falls back to plain text on purpose, because that beats stray symbols. I changed it and nothing happened. The setting applies from the next reply onwards. Also confirm you saved the right Robô if the account has more than one. See also - Advanced model settings - Service sequence
🧠 Maestro AI & Account BrainAI usage: what your account spent, and where
Overview Every time the platform uses an AI model — the Robot replying to a customer, a dashboard being generated, the onboarding briefing, the quality judge, the copilot, a voice call — that costs money, measured at the moment of the call. The Brain's Usage tab gathers those costs and answers the question that comes up every time the invoice arrives: what did THIS account spend, and on what. The figure is not an estimate. It is the sum of the measurements taken on each call: how many calls, how many tokens went in, how many came out, how many were served from the provider's cache (billed at a discount), and what it cost. Prerequisites - The Brain module must be enabled on the account. - You must be an administrator. This is the only Brain read restricted to administrators, for a simple reason: invoice information is not support information. An agent reading the inbox does not need to read the bill. - The AI service must be reachable. If it is not, the screen shows an error — never a zero. Step by step 1. Open Brain in the sidebar. 2. Go to the Usage tab. 3. Pick the period in the top right: 7, 30 or 90 days. The window IS the question: changing the period reloads the numbers. 4. Read top to bottom: - the four cards summarise the whole period — cost, calls, tokens and cached tokens — and each one carries underneath the average that is usually the next question: cost per day, calls per day, tokens per call and how much of the prompt came from cache (that is the provider's discount: when the percentage drops, the bill rises without the volume moving); - the chart shows spend day by day, with the scale on the left, dates along the bottom, the peak day highlighted and, in the footer, how many days of the period actually had spend — a nearly flat line reading "3 of 90 days with spend" is information, not an empty chart; - the lists below break the same total down by surface, by model and by Robot, each row with its share of the total, its call count and its cost per call; - the Per conversation section lists the most expensive conversations of the period, each with a link that opens the conversation, its cost, how many turns it had and its cost per turn. 5. Use the filter bar at the top to cross the questions: surface, model, Robot and conversation. The filters combine, and they redo the read — they do not hide rows on screen, they change the query. Filtering by one Robot and watching the total drop is the confirmation that this Robot accounts for that share. Amounts below one cent are shown with the decimals they need (for example US$ 0.004933). A model call costs fractions of a cent: rounding to two decimals would print US$ 0.00, which reads as "nothing was measured". Per conversation Until now this screen answered "what did the account spend". Per conversation answers "what did THIS conversation cost" — the question that comes up when one conversation drags on, or when someone wants to know whether a particular case turned out expensive. A conversation's cost includes what it spent outside the reply turn: transcribing the audio the customer sent, the audio the Robot replied with, the voice call. Those used to land in a row that could not be linked back to the conversation that caused them. Sub-agents and delegation. When a Robot delegates to a sub-agent, the sub-agent's tokens are already counted on the caller's turn. The screen shows the delegation so you know it happened, but its cost is not added again — adding it would count the same tokens twice and inflate exactly the number this screen exists to make trustworthy. Unpriced surfaces Not everything that consumes AI has a price table. Audio transcription is billed per second, speech synthesis per character, image and video per unit — and the platform does not have the price table for those. So they show up counted and labelled, measured in their own unit ("3,412 characters synthesized"), and never as US$ 0.00. The distinction is the whole point: US$ 0.00 reads as "this was free". A surface labelled unpriced reads as "this consumed something, and the platform does not know what it cost" — which is the truth. The priced total remains a trustworthy total; it simply is not the whole invoice, and the screen says so instead of letting you add it up wrong. Settings & options There is nothing to configure here: the tab is read-only. What moves the numbers is usage — how many conversations the Robot handles, how many dashboards get generated, whether the quality judge is sampling turns, and which model each Robot uses. To change a Robot's model (and therefore its cost per call), use the Robots screen. To change who grades quality, use the Brain's surface assignment. Use cases - Closing the month. You get the provider's invoice and want to know how much of it is this account. - Finding where the money goes. Almost always the answer is "customer replies" — it is the surface that runs most often. When it is not, that is worth a look: a dashboard generated over and over, or a judge pointed at an expensive model, shows up immediately in the by-surface list. - Comparing Robots. The per-Robot breakdown shows which one consumes most, which usually reflects conversation volume rather than waste — but sometimes reflects an expensive model chosen without need. - Seeing the cache work. Cached tokens are billed at a discount. A high number there means the system prompt is stable and being reused; a sharp drop usually means something in the prompt changed. - Investigating an expensive conversation. The Per conversation section sorts by cost. Opening the most expensive one and checking its turn count separates two different causes: a long conversation (many cheap turns) and a heavy one (few expensive turns, usually a large model or a lot of context). - Finding the cost of voice. Filter by the audio surfaces to see how much transcription and synthesis the account consumed — in seconds and characters, since no dollar price exists for them. Tips, limits & best practices - Values are in US dollars. That is the currency the provider bills in and the measurement was taken in. Converting here would invent an exchange rate the platform never observed. - The by-model breakdown is partial, and the screen says so. Customer replies are measured without recording which model replied, so their cost lands in the total, in the by-surface list and in the daily chart, but not in the by-model list. When that happens, a line states how much of the total the list covers. Adding up only the by-model list and taking it for the whole bill is exactly the mistake that line exists to prevent. - No spend in the period is not an error. If the account genuinely did not use AI, the screen explains that. If the service is down, it shows an error with a retry button. The two situations are different and the screen never swaps one for the other. - The maximum window is 365 days. Longer periods are clamped, not refused. - A day with no spend shows as a day with no spend — not as a gap in the line. Troubleshooting The tab does not appear. The Brain module is disabled on the account, or you are not an administrator. An error shows instead of the numbers. The AI service did not answer. Nothing is rendered as zero on purpose: a made-up figure here would be worse than none. Use Try again; if it persists, it is one for whoever runs the installation. The total does not match the provider's invoice. Two common causes: the invoice covers the whole installation (every account) while this screen covers one account; and the price table used at measurement time may be out of date with the provider. Talk to whoever runs the installation. The by-model list adds up to less than the total. Expected, and the screen warns about it — see "Tips, limits & best practices" above. A surface shows calls but no dollar amount. That is deliberate: transcription, speech synthesis, image and video have no price table in the platform. Their measurement is in their own unit (seconds, characters, units). That is not the same as zero cost, and the label exists precisely so you do not confuse the two. The by-surface and by-conversation totals do not match exactly. A conversation only appears under "Per conversation" if its spend could be linked to it. Account work that belongs to no conversation — a generated dashboard, the onboarding briefing, the daily improvement cycle — counts toward the total and the surfaces, and correctly counts toward no conversation. See also - Analytics and generative dashboards - Advanced model settings
🧠 Maestro AI & Account BrainWeb search: the bot looking things up on the public internet
Overview Web search gives the bot two tools for querying the public internet — things it does not know and that do not live in your account: news, market prices, public company data, documentation, anything that changed after the model was trained. | Tool | What it does | |---|---| | web_search | Searches the web and returns ranked results with the title, URL and a snippet of each page. | | web_fetch | Reads the full text of specific pages by URL — after a search when the snippet is not enough, or whenever the bot already has the URL. | Both are read-only and send the contact nothing: they return text to the model, which then decides what (if anything) to say. That is also why they stay available when the bot delegates to a sub-agent. For your account's own content — contacts, deals, catalog, history — the bot has dedicated tools, and the knowledge base holds your material. Web search is for what lives outside. Prerequisites - Maestro enabled and a configured bot. - A Tavily API key available to the bot (see "The key" below). - The web_search and/or web_fetch tools enabled in the bot's tools grid — without them, nothing in this section has any effect. Step by step 1. In the bot's configuration, open the Tools grid and enable Search the web and/or Read a web page (Knowledge category). 2. Scroll to the Web search section. If neither tool is on, a notice tells you nothing there will take effect yet. 3. Adjust Search depth and Results per search. 4. To restrict it, fill in Search only these domains and/or Never these domains. 5. Save. To switch search off entirely, disable both tools in the grid. Your settings are kept for whenever you turn them back on. Settings & options | Option | What it does | Default | |---|---|---| | Search depth | Basic or Advanced. Advanced reads more of each page and matches better, but costs more credits per call. It also applies when web_fetch reads a page. | Basic | | Results per search | A ceiling of 1 to 20. Empty = the tool default (5). | Empty (5) | | Search only these domains | Restricts search to those domains. Empty = the whole web. | Empty | | Never these domains | Always blocks those domains. | Empty | How the two domain lists combine They do not work the same way, and the difference is deliberate: - Search only these domains is a restriction. When you fill it in, the bot's own list is ignored — it cannot search anywhere else, not even if it asks. A restriction the model can widen is not a restriction. - Never these domains is a blocklist. Your domains always apply, and the bot may still add more for a specific query. Type domains separated by commas or newlines. https://, www. and any path after the slash are stripped automatically — Tavily matches hosts, so https://example.com/pricing becomes example.com. What the bot decides (and you do not) - How many results to request for that query: it may ask for fewer than your ceiling, never more. - The topic of the query (general, news or finance) and the time window (past day, week, month or year), decided per question. Neither has a fixed per-bot field today — the default is general, with no time filter. - Which URLs to read with web_fetch — at most 5 per call. The key (Tavily) Search needs a Tavily key. It is looked up in this order: 1. The bot's own key (API keys section, provider tavily). 2. Your account's key, under Integrations. 3. The installation's key, configured by the operator. With none of them, the tools reply that search is not configured and the bot carries on with what it already knows — the conversation does not break. Use cases - Technical support — check a partner's public documentation before advising the customer. - Pre-sales — look up public data about the contact's company to qualify better. - News and prices — answer about something that changed after the model was trained. - Restricted base — put your own site and documentation in Search only these domains: the bot searches only there, like an internal search over public content. Tips, limits & best practices - Every search consumes Tavily credits. Advanced depth and a high result count multiply the spend — start on Basic with the default of 5. - An extra result is also extra context in the turn: 20 results can push the conversation's own information out. - web_fetch reads at most 5 pages per call, and each page's text is truncated to fit the turn. - A URL that could not be read is reported to the bot, not silently dropped — so it does not answer as if it had checked. - The public web is not a source of truth about your operation. For your prices, policies and lead times, use the knowledge base. - Pair it with turn verification if you want to hold replies that claim something the turn did not establish. Troubleshooting - "I configured everything and the bot never searches" — are the web_search/web_fetch tools enabled in the grid? The notice in the section tells you when they are not. - "Search is not configured" — there is no Tavily key at any of the three levels. - "The API key is invalid" — the key exists but was rejected; issue a new one at Tavily. - "The plan limit was reached" — the Tavily account is out of credits. - "Search is rate limited right now" — too many calls in a short window; it retries later. - "It searched a site I did not want" — add the domain to Never these domains, or lock everything down with Search only these domains. - "Results come from another country/language" — make the query more specific in the bot's instructions and restrict by domain. See also - What Maestro AI and the Account Brain are - Maestro tools by module - Knowledge base and ontology - Verifying what the bot claims