Finance & Accounting
Connect WhatsApp Business API and Zoho Books
The invoice raised where the accountant expects it, and everyone who moves the order told on WhatsApp.
- Connects
- WhatsApp Business API and Zoho Books
- Data flows
- 5 automated, two-way where safe
- Built with
- WhatsApp Business API, Zoho Books API, AiSensy
- Timeline
- Live in 3 to 5 business days from scope
- Owned by
- You. Accounts, credentials and code in your name.
In short
Connecting WhatsApp Business API to Zoho Books means an order confirmed by your team raises the invoice in Books, and approved WhatsApp templates tell the customer, warehouse keeper and transporter what happens next. SBD built this for a building materials supplier, with invoices and their PDFs coming from Zoho Books, not a copy.
The workflows
What runs between WhatsApp Business API and Zoho Books.
Each line is one automated workflow. An event in one tool, the checks and mapping in between, the action in the other, and the person who hears about it.
-
Invoice from the confirmed order
WhenAn order is confirmed in the order system
Automation- Verify and validate
- Map and normalise
- Upsert by key
ThenCreate the invoice in Zoho Books against the synced contact and items, and write the Books invoice number back to the order
And- Audit log entry
- Alert if it fails or goes quiet
- Review queue if unsure
-
Loading slip to the warehouse keeper
WhenA loading slip is raised, one per brand per order
Automation- Verify and validate
- Map and normalise
- Upsert by key
ThenSend the warehouse keeper an approved template with the slip details and PDF
And- Audit log entry
- Alert if it fails or goes quiet
- Review queue if unsure
-
Pickup notice to the transporter
WhenA load is ready for pickup
Automation- Verify and validate
- Map and normalise
- Upsert by key
ThenSend the assigned transporter the pickup template with site, vehicle and order reference
And- Audit log entry
- Alert if it fails or goes quiet
- Review queue if unsure
-
Invoice PDF to the customer
WhenThe invoice is created in Zoho Books
Automation- Verify and validate
- Map and normalise
- Upsert by key
ThenSend the customer a utility template carrying the invoice PDF from Books
And- Audit log entry
- Alert if it fails or goes quiet
- Review queue if unsure
-
Failed sends caught the same day
WhenA template send fails or a template is paused
Automation- Verify and validate
- Map and normalise
- Upsert by key
ThenLog it against the order and alert a named person, rather than retrying silently
And- Audit log entry
- Alert if it fails or goes quiet
- Review queue if unsure
Every record passes through the same stages
- 1Receive
Webhook or polling from the source tool, with a signed payload and a replay log.
- 2Validate
Required fields present, types right, record key found. Anything else goes to the review queue.
- 3Map
Fields translated to the destination schema. Enumerations, currencies and dates normalised.
- 4Upsert
Written against the record key, so a retry updates rather than duplicates.
- 5Confirm
Outcome logged. Alert if the count goes quiet. Reconciliation run nightly.
Read this first
Why the obvious route breaks.
A one-step Zap connects WhatsApp Business API and Zoho Books in an afternoon. This is what goes wrong once real volume and real edge cases arrive.
Keepers and transporters never message you first
Free-form WhatsApp messages can only be sent inside the 24-hour customer service window that opens when a person messages the business. Warehouse keepers and transporters are told about loads; they rarely start the chat. So every message to them must be a pre-approved template, designed and submitted before go-live.
Each audience needs its own templates
A customer needs the invoice, a keeper needs the loading slip for one brand, a transporter needs the pickup. The building materials build runs nine templates across those three audiences. Templates must be approved before they can be sent, review can take up to 24 hours, and a template can be paused for poor feedback or low read rates.
Zoho Books caps calls per day by plan
Zoho Books allows 100 requests a minute per organisation and a daily cap tied to the plan, from 1,000 on Free to 10,000 on Premium and above. One order can need a contact check, item lookup, invoice and PDF. An integration that re-reads every invoice to decide who to message runs out of calls mid-afternoon.
Tokens expire hourly and the domain depends on region
Zoho access tokens last one hour, every request carries the organisation ID, and an organisation on the India data centre uses the .in API domain rather than .com. A sync built against the wrong domain or a stored access token fails the first time it runs unattended.
What it costs today
The gap, as the team feels it and as the engineer sees it.
In the team
- Transporters and keepers are phoned one by one for every load
- Invoices are typed into Zoho Books after the order has gone
- Customers ask for the invoice copy on WhatsApp anyway
- Nobody knows if the keeper saw the loading slip
- Accounts and dispatch keep separate versions of the order
Under the hood
- Business-initiated messages need approved templates
- Zoho Books daily call caps by plan
- Hourly access token expiry and per-region API domains
- Organisation ID required on every Books request
- Templates can be paused on quality, mid-month
What we wire up
The data flows.
- 01 When
An order is confirmed in the order system
ThenCreate the invoice in Zoho Books against the synced contact and items, and write the Books invoice number back to the order
- 02 When
A loading slip is raised, one per brand per order
ThenSend the warehouse keeper an approved template with the slip details and PDF
- 03 When
A load is ready for pickup
ThenSend the assigned transporter the pickup template with site, vehicle and order reference
- 04 When
The invoice is created in Zoho Books
ThenSend the customer a utility template carrying the invoice PDF from Books
- 05 When
A template send fails or a template is paused
ThenLog it against the order and alert a named person, rather than retrying silently
Used for
- Invoice from the confirmed order
- Loading slip to the warehouse keeper
- Pickup notice to the transporter
- Invoice PDF to the customer
- Failed sends caught the same day
- Zoho Books invoices from an order app
- WhatsApp invoice delivery from Zoho Books
- WhatsApp updates for warehouse and transport
- Products and taxes kept in step with Zoho Books
- Building materials and distribution order flow
Built with
Data map
What becomes what, and what it is keyed on.
| In WhatsApp Business API | In Zoho Books | Matched on | Direction |
|---|---|---|---|
| Template sends to customers | Invoice record, by Books invoice number | Zoho invoice ID | one-way |
| Template sends to keepers and transporters | Loading slip and trip on the order | Order and slip reference | one-way |
| Customer phone numbers | Contacts in Zoho Books | Zoho contact ID | two-way |
| Message delivery status | Order trail entry | Message ID | one-way |
Field-level mapping is agreed in the blueprint and written into the runbook. Two-way rows carry loop protection so a write from the sync never re-triggers the sync.
In every build
What you get with the sync, whichever pair.
Under the hood
- Upserts keyed on the record
Every write is matched on the source ID. A retry or a re-fire updates the existing record instead of creating a second one.
- Retries with backoff
Rate limits and timeouts are retried with increasing delays, then parked for review, never dropped.
- Idempotent, loop-safe writes
Two-way flows carry a marker so a change written by the sync does not re-trigger the sync.
- Reconciliation
A nightly job compares counts and totals on both sides and lists any record that differs.
- Audit log
Every run records input, mapping result, action taken and who or what triggered it. Searchable by record.
- Error monitoring
Loud failures alert within minutes. Quiet ones are caught by an outcome count that alerts when it stops moving.
- Review queue
Records the sync is not sure about land in a screen a person can read, correct and release.
- Scoped credentials
One credential per connection, limited to the objects it needs, stored encrypted, in your account.
For the team
- Slack or email notifications
The alerts go to a named person, not a channel nobody reads. You choose Slack, email, WhatsApp or all three.
- A runbook
One document per integration: what it does, what each alert means, and what to do in the first ten minutes.
- Training
A live session with the people who will use the review queue, recorded for whoever joins later.
- Handover
Admin access, billing and code sit in accounts in your name from day one. If we leave, it keeps running.
- Sixty days of hypercare
The engineers who built it stay on call after go-live, fix what breaks and tune what the team asks for.
- A monthly report
Runs, records synced, exceptions handled, and what changed. Plain language, one page.
Security and your data
Where the data goes, and who holds the keys.
- Accounts
- Every platform account is created in your name. We work through managed access you can revoke.
- Credentials
- Stored encrypted in the orchestration layer. Scoped per connection. Rotated on handover.
- Data in transit
- TLS everywhere. Webhooks verified by signature before anything is processed.
- Data at rest
- Only what the sync needs. No copies of your customer data on our machines.
- AI steps
- Where an integration uses a model, it is through a business API that does not train on your data.
- Retention
- Run logs kept 90 days by default, adjustable. Payloads redacted of card and ID numbers.
- Agreements
- DPA and NDA on request. Regional rules covered in our privacy policy.
Keys and sensitive data
How API keys, tokens and personal data are handled.
- Keys live in a vault, never in code
API keys and tokens are stored in the orchestration layer's encrypted credential store or the platform's secret manager. None are written into workflows, repos, spreadsheets or chat.
- One credential per connection
Each integration gets its own key, scoped to the objects and actions it needs. A lead sync cannot read invoices. Revoking one key stops one thing.
- Service accounts, not personal logins
Connections use a dedicated service user in your account, so nothing breaks when a person leaves and nothing runs under someone's name.
- Two-factor on every account
Every platform account we set up has two-factor authentication on, with recovery codes handed to you, not kept by us.
- Rotation on handover and on request
Keys are rotated when the build is handed over, when anyone with access leaves, and at any time you ask.
- Secrets never reach the logs
Audit logs redact tokens, card numbers, government IDs and anything you flag as sensitive before a line is written.
- Webhooks verified before processing
Inbound calls are checked against the sending tool's signature. Unsigned or stale payloads are dropped and counted.
- Access you can see and revoke
Our access is through managed roles in your accounts. You can list it, limit it, and remove it in one click without touching the build.
Engineering decisions
Decided before the first workflow is written.
- Rate limits and backoff
Every API has a ceiling. Calls are batched, queued and retried with increasing delays so a busy hour does not become a failed one.
- Backfill and pagination
The first run has to load history, not just new events. Backfills page through the source in order, resume after interruption, and never double-write.
- Out-of-order and duplicate events
Webhooks arrive twice and out of sequence. Each event carries a version or timestamp, and older versions never overwrite newer state.
- Schema changes
A renamed field or a new dropdown value is the most common silent failure. Payloads are validated against a contract, and a mismatch stops the run and raises a flag.
- Time zones, currencies, units
Dates are stored in UTC and shown local. Money carries its currency. Quantities carry their unit. Conversions happen once, in the map step.
- Sandbox first
Builds run against sandbox or test accounts with seeded data before they touch production. Go-live is a switch, not a rewrite.
- Versioned and reversible
Workflows and code are version-controlled. A release can be rolled back in minutes without losing the records processed since.
- API deprecations watched
Tools retire API versions on a schedule. We track the dates for every connection in the runbook and upgrade before the cut-off.
- Cost per run known
Each workflow has a cost per execution, including any model calls, logged alongside the run. You see the bill before it arrives.
- Metrics, not just errors
Runs per hour, records in and out, exception rate and latency are charted. Trends show a problem before an alert does.
Proof
Where we have done this.
The offer
Hire SBD to connect WhatsApp Business API and Zoho Books.
A fixed scope, agreed in a discovery call, and live in three to five business days. Accounts in your name. The engineers who built it on call for sixty days after.
- ScopeOne call to agree the flows, the fields and the owner. Written up the same day.
- Build5 workflows, the data map above, validation, upserts, retries and reconciliation.
- Go-liveSandbox first, then a switch. Day three to five from scope for most pairs; longer only if a tool needs approval, such as WhatsApp templates.
- HandoverRunbook, training session, alerts to a named owner, admin access and code in your accounts.
- AfterSixty days of hypercare, then a care plan or run it yourself.
Questions
What people ask about this pair.
Do we need the official WhatsApp Business API for this?
Yes. Automated messages to customers, keepers and transporters need the official API, reached through Meta directly or a provider. The building materials build sends through AiSensy. Every business-initiated message uses an approved template, so template design is part of the scope, not an afterthought.
How is WhatsApp charged now?
Meta moved from conversation-based to per-message pricing on 1 July 2025, and charges when a message is delivered. Rates differ by country and by template category, such as utility for order and invoice updates and marketing for promotions. We size the monthly cost from your real order volume during scoping.
Who creates the invoice number?
Zoho Books does. We send the contact, items and taxes, and Books applies your numbering and tax settings. The number comes back and is stored on the order, so the WhatsApp message, the order and the ledger all quote the same invoice.
What did the original system run on?
The first version ran on Retool with AiSensy for WhatsApp. Its custom-coded successor, now in build, runs on Supabase with the same Zoho Books and WhatsApp connections, and holds the messaging key as a secret rather than inside app queries.
Related
-
Zoho Books and Airtable
Invoice from the event that earned it, and see what is outstanding without opening Books.
-
WhatsApp and Airtable
Reach customers where they reply, with the conversation logged against the record.
-
Tally and WhatsApp Business API
Overdue invoices from TallyPrime, chased on WhatsApp at the frequency each customer warrants.
- Solution
Order to cash
Every workflow we automate for this kind of team.
Keep exploring
Related to this page
- IntegrationTally and WhatsApp Business API Automation
- SolutionDistribution automation for stock, deliveries and cash
- SolutionRetail and wholesale automation, built around how you sell
- Customer storyOrder and dispatch management system
- IntegrationZoho Books and Airtable Automation
- BuildBuilt with WhatsApp Business API
WhatsApp and Zoho Books
Invoice in Books, message on WhatsApp, from one confirmed order.
Invoices raised in Zoho Books from the order, and approved templates to customers, keepers and transporters at each step, built in three to five business days after templates are approved.
Start with a discovery call