Connect WhatsApp to the system that holds the answer.
Connect a WhatsApp conversation to the order, payment, booking, lead, shipment, spreadsheet, or file behind it. Use this guide to compare what each connector reads, what it can change, which events it receives, how it is authorised, and what happens when the provider is unavailable.
In one line
Waaru publishes the action, event, permission, setup, and failure boundary for every listed integration. The provider logo alone is never treated as proof that a workflow can complete your exact job.
Integration guide reviewed .
No credit card. No commitment.
Keep the provider reference with the conversation.
A useful handoff carries the exact order, payment link, appointment, shipment, lead, sheet row, or file reference into the next step. That lets the workflow retrieve one bounded record, explain the result to the customer, and give a teammate enough context when a person needs to take over.
ExampleConnected journey data
WhatsApp keeps the reference
The workflow can use the relevant Shopify record without losing the customer reference.
Integrations
Review each integration before adding it to a customer journey.
Open a provider page to review its current reads, writes, events, authorisation method, setup requirements, and exclusions. Availability refers to the shared public catalogue. Your provider account can still require permissions, approval, configuration, or acceptance testing.
A connector directory does not tell you whether the workflow is usable.
Two products can display the same provider logo while exposing very different operations. One may read an order but not update it. Another may receive a payment event but not verify or reconcile it. A third may request more account access than the task needs. Evaluate the operational boundary before designing the customer journey.
Confirm the exact record the workflow can find and the identifier it needs.
Separate read-only lookups from writes that change business or financial state.
Check how duplicate, delayed, failed, or out-of-order provider events are handled.
Verify the provider account, permissions, regional availability, and production approval required for setup.
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.
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.
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 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.
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.
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.
A WhatsApp integration connects a conversation or workflow to a bounded record or event in another business system. It may read information, make an approved change, receive a provider event, or combine those operations. The useful boundary is the exact action and permission, not the presence of a provider logo.
Sources & references
Primary references for integration access and events.
Provider documentation establishes the available external mechanism. Waaru's registered runtime catalogue determines the narrower actions and events exposed by the product. Each provider page cites the references specific to its capability boundary.
1
Razorpay Technology Partners can onboard businesses through OAuth rather than collecting merchant API keys.
Bring one real workflow to the integration review.
Start with the customer question, the provider record that answers it, and the action that must happen next. We will verify the connection, permissions, failure path, and handoff before you rely on it.
