Connect WhatsApp to your business tools.

Choose well

Choose the system that owns the record.

Start with the business record that can answer the customer's question. Shopify or WooCommerce should own store orders and product data. Razorpay should own the state of a hosted Payment Link or payment. Google Calendar or Cal.com should own the appointment. Shiprocket should own the shipment and delivery exception. Zoho CRM should own the sales follow-up. Google Sheets can be the bounded operating record for a smaller team that has not adopted a CRM, PMS, or specialist booking system. WhatsApp is the conversation layer in this model. It should not become a second, conflicting copy of the provider record. Keep the provider ID with the workflow run, fetch only the record needed for the next step, and present the useful result in the conversation.

• Use an order or fulfilment ID for a store question instead of searching broadly by phone number.
• Use the provider payment or link ID when confirming a financial outcome.
• Bind an appointment to the selected calendar and managed event reference.
• Keep CRM notes, spreadsheet rows, and private files attached to the workspace that authorised them.

Separate reads, writes, and events.

A read answers a question without changing the provider. Examples include checking one order, finding available time, reading payment status, or retrieving shipment tracking. A write changes business state. Creating a payment link, booking an appointment, updating a lead, appending a selected sheet range, or recording an NDR decision needs a clearer permission and recovery policy. An event starts with the provider. An order update, captured payment, changed booking, or shipment scan can continue a workflow only after Waaru can identify the connected account, validate the delivery, reduce it to an approved event contract, and prevent a duplicate delivery from repeating the customer-facing action. Each integration page lists its current reads, writes, and events separately so you can check the complete path before relying on it.

Use the narrowest integration that can complete the job.

Choose a direct connector when the workflow depends on a provider-specific record, financial result, signed event, or tightly bounded permission. Direct connectors make the available operations and failure rules explicit. Use Zapier when the handoff is smaller and its reviewed trigger or action covers the job. A new inbound message or contact can start a Zap, while approved contact actions can keep a selected external process in sync. Do not choose an automation connector only because it lists more apps. Confirm the trigger, fields, write behaviour, retry model, and ownership of the resulting record. If the task needs raw HTTP, arbitrary commands, unrestricted provider responses, or a financial mutation that the connector does not publish, it is outside the supported boundary.

D2C, ecommerce, and retail

Keep order, payment, and delivery answers attached to one journey.

A commerce conversation often crosses several systems. The store holds the order, customer, product, stock, and fulfilment context. Razorpay holds the hosted Payment Link and verified payment state. Shiprocket holds serviceability, shipment, tracking, courier, and non-delivery information. Waaru should carry the relevant references between those steps without pretending that one connector owns every record. For a D2C or ecommerce team, useful starting journeys include answering an order-status question from the current store record, checking product availability before a teammate promises it, creating a fixed-amount hosted payment link after the amount is confirmed, and explaining a shipment exception with the current logistics state. Retail teams can use the same pattern for assisted purchases and follow-up, while keeping store and payment changes explicit. Review the Shopify, WooCommerce, Razorpay, and Shiprocket pages before treating a combined journey as production-ready.

Hospitality and bookings work best when availability stays authoritative.

A hotel, hostel, restaurant, clinic, consultant, or appointment-led service should decide which system owns availability before adding WhatsApp. Google Calendar can work for teams that manage selected calendars directly. Cal.com can work when the business already operates event types, schedules, and booking rules there. A spreadsheet may support a simpler operating process, but it needs a clearly selected range and an owner who understands when the data is updated. A reference booking journey checks the authoritative availability, captures the customer details required for the appointment, creates the managed booking, and returns a confirmation in WhatsApp. If a deposit is required, the amount and booking reference should be confirmed before a hosted Razorpay Payment Link is created. Payment still completes on Razorpay's hosted page. The provider-confirmed result, not a customer message or link click, determines the next financial step.

• Hotels and hostels can keep room enquiries, reservation references, and deposit status understandable to reception.
• Restaurants and event teams can use a selected booking calendar rather than a second availability list inside chat.
• Slot-booking businesses can define reschedule, cancellation, expiry, and human-review paths before opening the journey to customers.

Services and appointment-led teams need a clear follow-up owner.

A completed booking does not finish the operational work. A clinic may need a reminder and a staff handoff without placing sensitive clinical detail in a general-purpose connector. A property team may need a site-visit appointment, a bounded lead update, and a task for the assigned owner. An agency or professional service may need to append an approved sheet row or update a CRM note after qualification. Use Zoho CRM when the sales team already works from contacts, leads, deals, notes, and tasks. Use Google Sheets when a selected spreadsheet is genuinely the team's operating record. Use Google Drive only for approved files or locations rather than broad account access. The WhatsApp message should explain the customer-facing result. The business record should remain in the system the team checks every day.

Setup

Connect an account without widening access.

Setup differs by provider. Some integrations use OAuth or a provider-managed installation. Others need a workspace administrator to authorise a specific account and select the resource the workflow may use. Waaru should never ask a merchant to paste a secret when the provider offers a safer managed authorisation method. It should also avoid treating a broad provider scope as permission to expose every operation. Before launch, confirm the environment, account owner, requested permissions, selected calendars or files, event subscription, and disconnect behaviour. Run one representative acceptance journey with a test order, booking, payment link, lead, shipment, sheet, or file. Then inspect both the customer message and the provider record. A successful connection badge proves that authorisation completed. It does not prove that every required action, event, permission, or production approval is ready for your workflow.

• Authorise the provider through its official connection or installation flow.
• Select only the account and resources the workspace needs.
• Review each requested read, write, event, and financial capability.
• Run a representative test and confirm the result in both systems.
• Document who can reconnect, replace, or disconnect the provider account.

Test the failure path before launch.

Provider integrations fail in ordinary ways. Access expires. A merchant revokes an app. A webhook arrives twice or out of order. A calendar changes between availability check and booking. A store or logistics API applies a rate limit. A financial request times out after the provider may already have accepted it. The workflow needs an answer for each case before it handles a real customer. Reads may retry when doing so cannot change provider state. Writes need idempotency and a provider-specific recovery rule. An ambiguous financial write must be reconciled instead of repeated blindly. Customer-facing messages should not claim success while the provider state is unknown. When the system cannot complete the approved next step, preserve the conversation context and route the operator to the provider record that needs review.

• Keep duplicate events from sending the same confirmation twice.
• Do not assume webhook events arrive in the order they happened.
• Do not retry an uncertain payment or other irreversible write without reconciliation.
• Give the teammate the provider reference, last confirmed state, and failed step at handoff.

How Waaru verifies an integration.

Provider documentation explains what an external API can offer. Waaru's registered action and event catalogue determines the smaller surface the product actually exposes. A public capability should have a named runtime path, strict input and output contract, workspace permission, provider-account boundary, failure policy, and focused tests. The integration page can then explain that behaviour in operator language and cite the relevant primary provider documentation. Live readiness needs separate evidence. Provider credentials, partner or marketplace approval, production permissions, deployed migrations, webhook delivery, and a representative staging or production acceptance test cannot be proven by a marketing page. Waaru keeps those external gates separate from source readiness. When an integration status changes, the shared catalogue should update its hub card, detail page, metadata, FAQ, structured data, sitemap representation, and agent-facing files together.