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.
Inboxes & Channels
WhatsApp Web and Cloud, Coexistence, groups/communities Hub, templates/flows/calls, website, email, social, voice and API.
Conversations & Support
Conversation view, replies, notes, assignment, status, priority, labels, macros, canned responses, search, filters and SLA.
Contacts & CRM
Contacts, import, segments, attributes, companies, pipelines/kanban/deals and orders registry.
Catalog & Commerce
Native catalog, sync and WhatsApp Business Catalog, sending products/orders in the conversation and e-commerce lifecycle.
Payments
Connect a gateway (Asaas/Mercado Pago), create charges (PIX/boleto/card), subscriptions, discounts, paid scheduling and reports.
Calendar & Scheduling
Connect Google Calendar, event types, availability, public booking page, reschedule/cancel, Meet and .ics.
Tasks
Lists, board and calendar, subtasks, dependencies, recurrence, reminders, SLA, templates and the in-conversation panel.
Follow-ups & Cadences
Sequences, steps, channels, composition, enrollment (manual/automation/event/inactivity/AI), funnel, exit and human-in-the-loop AI.
Automation & Flows
Automation rules, macros, Flow Builder, smart routing, bots and Captain.
Maestro AI & Account Brain
What Maestro is, voice onboarding, generative copilot (proposeβconfirmβexecute), departments, risk, insights and per-module tools.
Growth & Marketing Studio
Page/Form Builder, AI Studio, social publishing, Ads/CTWA/leadgen, launches, launch groups, social automation and Collaboration Network.
Contracts & E-signature
Issuing companies, A1 certificate, templates, variables, auto-fill, internal/external signing, public page and validator.
Sales & Gamification
Sales management, books of business, goals, goal-over-goal, gamification, leaderboard, rewards, commissions, wallboard and lead score.
Media
Media library, folders, trash, storage meter and reusing files across any channel.
Internal Chat
Channels, direct messages, announcements and sharing entities (conversations, contacts, deals) as cards.
Reports & Analytics
Overview, conversations, agents, teams, labels, inbox, CSAT, SLA and per-module reports.
Campaigns
Website campaigns, WhatsApp campaigns, HSM templates and variables.
Administration & Settings
Account, agents, teams, roles and governance (RBAC), business hours, labels, attributes, integrations, audit, whitelabel, scripts and notifications.
API & Developers
REST API, tokens, webhooks, Custom Scripts SDK and per-module events.
FAQ & Troubleshooting
Frequently asked questions, common errors (WhatsApp disconnected, pairing, failed payment), limits and anti-ban best practices.
Popular articles
What other people are reading right now.
Settings: timezone, quiet hours and send limits
Overview The Follow-ups Settings layer holds the controls that govern when and at what pace your cadences send: timezone, quiet hours, per-contact limit, send throttle (anti-ban), business days and the defaults for each new sequence. Instead of repeating these in every sequence, you set them once and all cadences obey. Each value is resolved by an order of precedence, from the most general to the most specific. The right-most one wins: code defaults β account default β per-inbox override β sequence β step In other words: the platform ships safe defaults; the account default adjusts everything at once; a per-inbox override changes just that channel; and, when it makes sense, a sequence or a step can refine further. This screen handles the two adjustable layers: the account default and per-inbox overrides. Prerequisites - The Follow-ups module enabled for your account. - An administrator user (only administrators can save settings). - For a per-inbox override: the inbox already created in the account. Step by step 1. In the Follow-ups module, open Settings. 2. Choose the scope: the account default (applies to every inbox) or a per-inbox override (pick the inbox in the scope selector). 3. Adjust the fields you need (timezone, quiet hours, limits, business days, defaults). 4. Click Save. The screen always shows the resolved configuration with precedence already applied, so you see the value that actually takes effect for that scope. 5. To send a field back to the account default, simply clear it in the override. Settings & options Timezone Sets the timezone used to compute waits, business days and quiet hours. There are two modes: - Automatic (recommended): stores no fixed timezone β the platform resolves it in order: the contact's timezone (when the toggle below is on and the contact has one) β the account timezone (the same one reports use) β the inbox timezone β UTC as a last resort. The screen shows which zone "Automatic" currently resolves to (e.g. "Automatic β account timezone: America/Sao_Paulo"). - Specific timezone: you pin an IANA zone (e.g. America/Sao_Paulo) that applies to that scope, ignoring the automatic resolution. Use the contact's timezone when available (default on, account scope only): when a contact has their own timezone, it outranks the account default for that contact's schedule only β handy for audiences across zones. Turn it off to treat everyone in the account timezone. Sequences and steps can refine further: a step's Scheduling section lets it inherit the resolved zone or set a timezone override for that step alone, and pick a fixed local time (e.g. "1 day later, at 09:00" in the resolved zone). Without the right timezone, "21:00", "business days" and the fixed time are interpreted at the wrong moment. Schedule preview: the sequence builder shows, per step, a preview of the next send already in the resolved zone (e.g. "~Mon 09:00 Β· America/Sao_Paulo (account timezone)"), so you can check the effect before publishing. Quiet hours A window in which nothing is sent β for example, 21:00 to 08:00. It has three parts: on/off, start and end. When a send would land inside the quiet window, it isn't dropped: it's pushed to the end of the quiet hours (the time the window reopens). The window can cross midnight (start later than end, like 21:00β08:00) and the platform handles that correctly. Quiet hours are off by default. Per-contact daily limit A safety cap on how many cadence messages the same contact can receive per day (rate_limit β per contact/day). The default is 3. It keeps several cadences combined from ever turning into spam for one person. Anti-ban send throttle Controls how fast a mass cadence dispatches, per inbox/connection (send_rate). You can set a ceiling per second and/or per hour. When volume exceeds the ceiling, the enrollments above the limit are deferred and re-queued β never dropped β and sent as soon as there's headroom. Blank fields use safe provider-derived defaults (for example, the WhatsApp Cloud per-second tier or the practical WhatsApp Web limit, around 240/h); 0 means no limit of its own. This is your main protection against a block on large sends. On WhatsApp Cloud, above the cadence's ceiling there is always the number's limit at Meta (80 messages per second at first, up to 1,000 once Meta releases the number, 20 on a coexistence number), shared by every automated send from the number: campaigns, follow-ups, flows, distribution and sales recovery. That limit applies even with the cadence throttle turned off or set to 0: turning it off removes only the cadence's own limit. Each kind of send counts against its own ceiling, so a running campaign does not block the cadence; the cadence uses what is left of the number's limit. Hold while an agent is attending (Maestro) Available when the account uses Maestro. With Hold the cadence while an agent is attending on, if Maestro pauses because a human took over the conversation, the follow-up neither enrolls that conversation nor sends the next step of an existing enrollment. Holding is not exiting. The enrollment stays active: the platform only defers the next step and re-checks periodically β the Re-check every (minutes) field sets that interval (default: 15). As soon as the agent lets go, the cadence resumes where it stopped. What actually ends a cadence is still a reply, a resolution or a goal. The setting is on by default β holding is the safe default. A held cadence loses nothing: it resumes on its own the moment the agent leaves the conversation. Ignoring the pause, on the other hand, sends the automated message on top of the reply the agent just wrote β and that mistake cannot be undone. If your operation wants the cadence running even with an agent on the conversation, turn the setting off at the scope you want, or pick Never hold on the sequence. Precedence is the same as the other options: account β inbox β sequence. Each sequence can Inherit, Always hold or Never hold in its own settings. While an enrollment is held, the timeline shows the reason "On hold (an agent is attending)". Business days The selected days permit every automatic send, including waits in minutes, hours or calendar days. The default is Monday to Friday. Business-day waits also count their delay using this list. The platform checks the resolved timezone, fixed send time and quiet hours again before sending. An overdue job cannot bypass the calendar. If no day is selected, sends stay on hold; the platform rechecks the calendar every 15 minutes once the step is due and resumes when an allowed window exists. Cadence defaults - Default compose mode: the initial mode of new steps (default: static, i.e. you write the text). It can be overridden per sequence/step. - Max steps: a ceiling on the steps actually sent per enrollment (default: 10), a guard against overly long cadences. Use cases - Respect business hours: turn quiet hours on (for example 20:00β08:00) and set the timezone so you never message a customer in the middle of the night. - Safe WhatsApp cadence (anti-ban): tune the per-second/per-hour throttle on the inbox so a large send drains at the connection's pace, with no risk of a block. - Per-inbox default: a billing channel with more conservative limits and a welcome channel with looser ones β each with its own override. Tips, limits & best practices - Get the timezone right first: it anchors quiet hours, business days and waits. - Keep the throttle on for WhatsApp inboxes and prefer to start conservative β it's better to drain slower than to risk a block. - Remember that blank throttle fields do not mean "unlimited": they fall back to the provider's safe defaults. Use 0 only if you really want to remove the limit. - A per-inbox override only changes the fields you fill in; the rest keep inheriting the account default. Troubleshooting - A message went out at dawn: quiet hours are off or the resolved timezone isn't your audience's ("Automatic" may be falling back to UTC because neither the account nor the inbox has a timezone). Turn quiet hours on and set the timezone β in Automatic mode, fix the account timezone; or pick a specific timezone for the right scope. - A step didn't send and I don't know why: open the enrollment timeline β each run shows the skip/failure reason (e.g. "Sequence not published", "No inbox for this channel", "WhatsApp 24h window closed", "Throttled (rate limit)", "On hold (an agent is attending)"), and the enrollment shows the failure reason at the top, never silently. - The cadence stopped sending but the enrollment is still active: most likely the Maestro hold β there is an agent on the conversation. It resumes on its own once they let go; if that isn't what you want, turn the setting off in the right scope or set Never hold on that sequence. - Sends are "lagging": that's the throttle holding the pace. Enrollments above the ceiling are deferred and re-queued (never lost); raise the per-second/per-hour limit if you want to go faster. - Business days weren't respected: check the resolved business days and timezone, including inbox, sequence and step overrides. The calendar applies to every automatic send. - I changed the account default but one inbox didn't change: it probably has an override with that field filled in β the override beats the account default. Attachments are sent in order, and each part checks the sending calendar. If a previous part fails or needs delivery verification, the remaining attachments are blocked. Email continuity notifications derived from automatic follow-ups also check the calendar immediately before delivery and are sent separately from ordinary reply summaries. Uncertain delivery If delivery becomes uncertain after contacting the provider, the message warns that it may already have been sent. Automatic retries are blocked to avoid duplicates. Check the provider's delivery record before sending another message. See also - Follow-ups and cadences overview - Sequences, steps, channels and composition - Cadence funnel and exit rules
π₯ Contacts & CRMCompanies and contact linking
Overview The Companies module lets you group contacts that belong to the same organization. Instead of treating each person in isolation, you start to see the corporate account: who the company's contacts are, how many interactions it generated and which deals are in progress. It is especially useful in B2B operations, where several contacts (purchasing, finance, support) talk to you on behalf of the same company. Prerequisites - The Companies module is optional and may depend on your plan. If you do not see it, it may be disabled for your account β ask an administrator. - Administration permission to enable and configure the module. - Have the contacts already created so you can link them to the company. Step by step 1. Confirm with an administrator that the Companies module is enabled for the account. 2. Create a company with at least a name (and, optionally, domain and description). 3. Link contacts to the company, associating the people from the same organization. 4. Open the company to see related contacts and the aggregated context. 5. Use company custom attributes to store specific data (segment, size, etc.). Settings & options - Company fields: name, domain, description and contact count. - Company custom attributes: extra fields created in the attributes area. - Contact linking: a contact can be associated with its company to inherit context. - CRM: a deal can be linked to a company (organization) in addition to the contact, connecting the opportunity to the corporate account. Use cases - Centralize all contacts of a corporate customer in a single view. - Track, in B2B, how many opportunities exist per company, not just per person. - Enrich reports and segments with organization data (size, market segment). Tips, limits & best practices - Use the company domain to standardize and avoid duplicate companies. - Link the right contacts: the module's value is in consolidation by organization. - Combine it with company custom attributes for richer analysis. Troubleshooting - I do not see the Companies module: it may be disabled for the account or for your plan β ask an administrator. - Duplicate companies: standardize by domain and merge repeated records. - Contact without a company: confirm it was linked to the correct organization. See also - Contacts and CRM overview - Contacts: create, import (CSV) and segments - Contact and conversation custom attributes - CRM: pipelines, kanban and deals - Organizations & Relationships: companies, roles and hierarchy
π Calendar & SchedulingCalendar reports and metrics
Overview Calendar reports are the analytics dashboard for the ConversaLabs scheduling module. On a single screen, an administrator follows booking volume, the no-show and cancellation rates, performance by event type and by agent, the lead time (how far ahead people book), the occupancy (booked hours), and the sync health with Google Calendar. These are aggregate numbers across an entire account (or one specific calendar) within a date range you choose. It is the managerial view of the Calendar β not an event-by-event list. Prerequisites - An account administrator profile. Reports are an administrative surface: agents without administrator privileges cannot open them. - The Calendar module enabled on the account (it is optional and off by default). - At least some bookings in the period so the numbers are not all zeros. Step by step 1. Open the Calendar from the left sidebar. 2. Go to the Calendar Reports section (visible to administrators only). 3. Choose the period (date range) you want to analyze. 4. Optionally, filter by a specific calendar. With no filter, the report covers the whole account. 5. Read each dashboard section to understand volume, rates, performance, and sync. Settings & options Reports include the sections below. Each one is computed over the selected period and calendar. | Section | What it shows | | --- | --- | | Overview | Total bookings and the split between confirmed, cancelled, no-show, and rescheduled, plus the cancellation rate and the no-show rate. | | By event type | Bookings per event type (e.g., "Demo", "Support"), with total, no-show, and cancelled for each type, sorted from most to least booked. | | By agent | Bookings per host (the responsible agent), with total and no-show for each β handy for comparing the team. Shows the top agents in the period. | | No-show rate | No-show count and its proportion over total bookings. | | Cancellation rate | Cancellation count and its proportion over the total. | | Average lead time | Average time between a booking's creation and the appointment's start β how far ahead people book. | | Occupancy | Booked hours and the number of events active in the period β a calendar utilization signal. | | Sync health | Sync events classified as ok, error, and conflict, plus the timestamp of the last sync with Google Calendar. | - Calendar filter: limits every section to a single calendar; without it, the report spans the whole account. - Period: sets the date window used in the counts and rates. - Payments funnel (optional): when the Payments module is active and the event type is paid, the report also shows settled revenue, the pending-to-paid conversion, and the expired, failed, and refunded cases. Use cases - Measure absenteeism: track the no-show rate and act (reminders, prior confirmation, prepayment). - Compare agents: see who receives the most bookings and who has the most no-shows, by host. - Track utilization: use booked hours and the number of events to assess the calendar load. - Monitor the integration: check sync health and the last sync with Google. Tips, limits & best practices - The numbers honor the scope you choose: the whole account or one calendar, within the date window. - Values are aggregate (counts, averages, and rates) β not a list of each booking. - The rates (no-show and cancellation) are proportions over the total bookings in the period. - Lead time considers only bookings whose start is later than their creation (the real lead). - Occupancy sums the duration of active events; cancelled/archived events are excluded. Troubleshooting - I cannot see Reports: the section is administrators only. If you are a regular agent, ask an account administrator for access. - The numbers are all zero: widen the period or remove the calendar filter β there may be no bookings in the selected window. - Conflicts appear under sync health: a conflict means a divergence between ConversaLabs and Google that the periodic check reconciles. Confirm the Google connection is still active and review the last sync; recurring errors may require reconnecting the Google account. See also - Calendar and scheduling overview - Connect Google Calendar (OAuth) and sync - Event types, availability, and buffers - Public booking page - Reschedule, cancel, Google Meet, and the .ics file
β TasksIn-conversation task panel
Overview The task panel is an embedded block that appears next to a conversation, on a contact's profile or in a CRM deal detail. From it you create and track tasks linked to that record β without leaving the support flow. Whatever needs to be done out of a conversation becomes a trackable task, with an assignee, due date and priority. The link is flexible: a task can be tied to a conversation, a contact and/or a deal. If the linked record stops existing, the task doesn't disappear or break β it simply loses the link. Prerequisites - The Tasks module enabled for the account. With the module off, the panel simply doesn't appear (no impact on the rest of the screen). - A conversation, contact or CRM deal open, where the panel will be shown. - User access to the account. Step by step 1. Open a conversation (or a contact's profile, or a deal in the CRM). 2. Find the task panel in the record's sidebar/detail area. 3. Click to create a task β it's born already linked to that record. 4. Set assignee, due date, priority and other fields just like any task. 5. Track the linked tasks and their status right there; open a task to see details, subtasks, comments and attachments. Tasks created from bookings and contracts A task created from a booking or contract preserves the conversation linked to the source record. Its contact and creation activity follow those links. Open the conversation and review the linked records before using the task to trigger a rule with a public message. A missing link is not replaced with a conversation carrying the same displayed number. Settings & options - Single link context: the panel shows the tasks for that specific record (conversation, contact or deal). - Creation in context: tasks created from the panel carry the link automatically. - Resilient link: if the conversation/contact/deal is deleted, the task remains (it just loses the link). - Automation: tasks can also be created automatically by automation rules from conversation events β combine with the panel for the full picture. Use cases - During a chat, open a "send proposal" task already tied to the conversation and the contact. - In a CRM deal detail, list everything left to close the sale. - Track a recurring contact's pending items right on their profile. - Standardize post-support by creating follow-up tasks linked to the conversation. Tips, limits & best practices - Create the task in context (from the panel) to guarantee the right link from the start. - Use clear due dates and assignees β the task will also show up in the list/board/calendar views. - Combine with reminders to resume the conversation at the right moment. - Don't rely on the panel to see ALL your tasks: the Tasks area shows the complete overview. Troubleshooting - The panel doesn't appear: the Tasks module may be off for the account β ask an administrator. - The task isn't linked to the conversation: it was probably created outside the panel; create it from the panel or review the link. - The linked record is gone: the task still exists in the Tasks area, just without the link. See also - Tasks overview - Views: lists, board and calendar - Task SLA and templates
ποΈ Catalog & CommerceOrder ingest endpoint
Overview The Orders registry accepts sales that happen outside the platform. You get an ingest URL of your own and POST each order to it β from your own checkout, an ERP, an automation, or any gateway ConversaLabs does not integrate natively yet. The URL carries an opaque token that identifies the account. There is no other authentication header: whoever holds the URL can register orders in your account, so treat it like a password. Prerequisites - The Orders module must be enabled for the account. With it off, the URL answers 404. - Administrator (or CRM management permission) to open and rotate the token. Step by step 1. Open Orders and click Ingest endpoint. 2. Copy the ingest URL. The Token field is masked β use the eye to reveal it and the button next to it to copy the token alone. 3. Paste the URL into your source system and send the order as shown below. 4. Confirm the order shows up in the list. Resending the same external_id updates the order instead of creating another one. curl -X POST 'https://YOUR-INSTALLATION/public/api/v1/orders/ingest/YOUR-TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "gateway": "my_checkout", "external_id": "ORD-10231", "email": "customer@example.com", "title": "Pro annual plan", "amount": 149.9, "currency": "USD", "status": "paid", "ordered_at": "2026-08-11T10:00:00-03:00", "line_items": [ { "name": "Pro annual plan", "quantity": 1, "unit_price": 149.9 } ] }' Body fields | Field | Required | What it is | |---|---|---| | gateway | Yes | Identifies where the order came from (e.g. my_checkout, hotmart). | | contact_id / email / phone_number | Yes (one of them) | A reference to find or create the contact. Send name too to label a new one. | | external_id | No, but recommended | The order's id in your system. It is what makes a redelivery idempotent. | | status | No | One of pending, partially_paid, paid, overdue, failed, canceled, refunded. | | amount and currency | No | Total in major units (149.9 = $149.90) and the ISO-4217 currency. | | ordered_at and paid_at | No | ISO-8601 timestamps with offset. Without them, the arrival time is used. | | line_items | No | Items with name, quantity, unit_price and, when available, catalog_product_id, catalog_variant_id, discount and metadata. | | title, crm_item_id, affiliate_id, metadata, raw | No | Extras. The affiliate is only credited when it belongs to this account and is active. | Responses - 201 β {"status": "ok"}. Order registered or updated. - 422 β invalid_payload (missing gateway), contact_reference_required (no contact reference), invalid_order_status (status outside the list) or contact_unresolvable (the contact could neither be found nor created). - 404 β token missing, already rotated, or the Orders module is off for the account. Settings & options - Configure the source, secret, and mapping only for fields that the integrator actually sends. Use cases - Receive orders from an external store and route them to the catalog and service flows. Tips, limits & best practices - Always send external_id. Without it, a redelivery from your gateway becomes a duplicate order. - The endpoint is rate-limited per token. For large loads, send serially and back off on 429. - Rotating the token invalidates the old URL immediately. Do it only with the integration ready to take the new URL β and update it right away. - Amounts go in major units, with a decimal point. Do not send cents as an integer. Troubleshooting - Everything answers 404: the URL was rotated, or the Orders module is off for the account. - 422 contact_reference_required: the body carried no contact_id, email or phone_number. - The same order appears twice: it was sent without external_id, or with a different value on each attempt. - The affiliate got no commission: the affiliate_id does not belong to this account, or it is inactive. See also - Sales reconciliation hub - Commerce lifecycle
ποΈ Catalog & CommerceSend a product/list and receive orders in the conversation
Overview With the catalog ready and synced, you can send products to the customer inside the conversation and receive their order back as a structured card. Instead of describing prices in text, you send the right item; when the customer builds a cart on WhatsApp, the order arrives organized, with items, quantities and a total β plus shortcuts to generate the charge. There are three ways to show products: single product, product list and open the catalog. And one way to receive: the order that becomes a card in the conversation. Prerequisites - A native catalog with products and, for native WhatsApp features, active sync with the WhatsApp Business Catalog. - A WhatsApp (Cloud API) Inbox β the native product, list and order formats work on the Cloud API. - An active storefront on the number, in the inbox's Catalog & Storefront tab. Meta creates every number with the storefront turned off: without activating it, sending a product fails with error #131008. See Catalog & Storefront in the WhatsApp inbox. - For an interactive single-product send over WhatsApp Web, an active Web inbox is enough; sending native carts and lists remains exclusive to the Cloud API. An order the customer sends from the cart also arrives on WhatsApp Web and becomes an order card when the platform can read its items through the connected number. - To charge the order: the Payments module configured. Step by step 1. Open the conversation with the customer. 2. In the composer, choose send product and select an item (single product) or build a product list. When there is more than one variation, choose the right one; when that variation has prices in more than one currency, choose the currency too. You can also open the catalog for the customer to browse. 3. On the Cloud API, the customer can add items to the cart. On WhatsApp Web, they use I'm interested or View product on the interactive card. 4. When the customer completes the cart, the order arrives in the conversation as an order card with items, quantities and the total. 5. On the order card, use Create charge or Create subscription to bill exactly what was ordered β the amount is pre-filled with the order total. 6. Track the payment in the Payments module; once confirmed, the customer receives the confirmation. Settings & options - Single product: sends a specific item from the catalog. - Variation and currency: the card uses the chosen variation and its registered price for the chosen currency; the selection never silently returns to the first variation. - Product list: sends several items grouped into one message while preserving each product's chosen variation and currency. - Open catalog: invites the customer to browse the catalog on WhatsApp. - Order card: shows items, quantities, total and the customer's notes. - Order shortcuts: Create charge (one-off payment) and Create subscription (recurring), already pre-filled with the order amount. - Referred product: when the customer replies quoting a product, an indicator of the quoted item appears next to the message. Use cases - A customer asks about a specific item β you send the single product with photo and price. - Consultative support β you send a list with the best options for the customer to choose from. - The customer builds the cart themselves β the order arrives ready and you bill in seconds. - A recurring sale (subscription/plan) β the order becomes a subscription with the agreed amount. Tips, limits & best practices - Charge what was ordered: the card uses the order total agreed with the customer; the amount is not recalculated from the current catalog prices. Billing the order respects exactly what the customer built. - Major-unit amounts: the total is the sum of price Γ quantity (4.97 = R$4.97), without dividing by 100. - Cloud API: the native format is used only when the chosen variation is published with its own retailer_id and uses the published currency. Otherwise, the platform sends the enriched card with the exact variation and price instead of substituting an item. - WhatsApp Web: a single product is sent as an interactive card with an I'm interested button and, when the record has a public link, View product. This send requires no additional license. - Review the order before charging: items, quantities and total. - Product names and photos: the platform looks up the product in this order: the platform's native catalog; what it already learned about the product from earlier orders; WhatsApp itself, through the connected number; and Meta's catalog, when the inbox token is allowed to read it. The name and photo may appear a few seconds after the card, without reloading the page. The price and quantity always come from the customer's order. - Hybrid inbox (Coexistence + WhatsApp Web on the same number): there is still a single card. The copy that arrives through WhatsApp Web only completes the product name and photo on the Coexistence card; it never creates a second message. Troubleshooting - The send failed with error #131008: the storefront is not usable on the number β either the catalog is not linked to the WhatsApp Business Account or the storefront is turned off. Open the inbox's Catalog & Storefront tab, select the catalog and click Turn on storefront for this number. Details in Catalog & Storefront in the WhatsApp inbox. - The customer didn't receive the native product/list: confirm the inbox is WhatsApp Cloud API and that the catalog is synced. Also check whether the selected variation has its own retailer_id; without it, receiving the enriched card is the expected fallback. - The order didn't become a card: check that the order came from the WhatsApp cart; orders from outside WhatsApp follow the e-commerce lifecycle. - Wrong amount when charging: the card pre-fills the order total; if you edit it manually, remember major units (don't divide by 100). - The card shows a code instead of the product name: the code is the product's identifier in the WhatsApp catalog. It appears when the product is not in the platform's native catalog and no other source provided the name β for example, when the number's catalog is the WhatsApp Business app's own catalog and the Cloud API token is not allowed to read it. On a hybrid inbox, the WhatsApp Web copy fills in the name and photo automatically. For a permanent fix, sync that catalog with the native catalog. The platform never makes up a name. - A WhatsApp Web order shows only the total, without its items: the platform could not read the order's items through the connected number, for example because WhatsApp Web was disconnected at that moment, or the items it read do not match the order's quantity and total. In that case the platform does not build a partial card, which would charge less than the customer ordered. The card shows what the message carried; confirm the items with the customer before charging. See also - Catalog & Storefront in the WhatsApp inbox - Native catalog: products, categories, images and prices - Sync and WhatsApp Business Catalog - E-commerce lifecycle Availability and delivery checks Before creating the outgoing message, the catalog checks availability and the prices represented in the card. A sold-out default is replaced by an available variation; an explicitly selected unavailable variation is rejected. A product with no available variations is not sent. One available variation produces one card, even if the product has several photos. Variations without inventory tracking remain available. Descriptions are sent without HTML markup. WhatsApp images are prepared in a compatible format; if preparation fails, replace the image and retry. An invalid price must be corrected in the catalog. A successful request means the message was queued; check its delivery status in the conversation. Automated sends retain the authenticated inbox bot as their author. Order history and quotes Cards received through WhatsApp Web show the product, total and updates actually contained in the message. A completed order update does not confirm payment: check the payment in the relevant module or provider. A product quote keeps its name and price when available and lets you return to the original message. This presentation also applies to older messages after reloading the conversation, provided the card data was preserved. Reloading does not resend an order or charge a payment. When source data never arrived, the platform does not invent items, amounts or payment confirmation.