ZOHO Integration
Zoho Books API Integration: Connecting Zoho With a Custom Application
Rakesh Bhetariya·
A while back, a company from the Gulf reached out with a very specific problem. They were already running their whole finance side on Zoho Books: invoices, customers, payments, all of it. Nothing wrong with Zoho. It worked. But they had one request that Zoho, out of the box, didn't answer the way they wanted:
"We want our customers to log into our own website and download their own invoices. We don't want to send them into Zoho."
I've heard some version of that question enough times now that it's worth writing down, because the answer catches people off guard. Most of the time, you don't replace Zoho to do this. You build around it.
I'd already built almost exactly this on an earlier project: a customer portal where a logged-in user could see their invoices and hit "Download," and behind the scenes the data was coming straight out of Zoho Books. The customer never knew. To them it was just a normal feature of the company's own website. That's the whole trick, really.
Here's how I think about these, and how the integration actually works.
Before writing a single line of code, I always ask one thing that occasionally talks a client out of hiring me: does Zoho's own customer portal already do what you need?
Zoho Books ships with a customer portal. Customers can log in and see their invoices, payments, statements, and transactions. If your requirement is simply "customers need to view and pay invoices," that portal might already be enough, and building a second one on top would only add cost and one more thing to maintain.
I'd rather say that upfront than build something you didn't need. It also tends to be the moment a client decides they trust you.
But sometimes the standard portal doesn't fit. That's a different conversation.
The Gulf company I mentioned already had a website their customers logged into. They didn't want to hand those customers a separate Zoho login and ask them to bounce between two systems. They wanted the invoice experience to live inside the product they already owned, under their own branding.
That's usually the real trigger. A custom portal earns its cost when:
In other words, the question stops being "how do we use Zoho" and becomes "how do we make Zoho work with the software we already run." That's an integration problem, not a replacement problem.
The core idea is simple. Zoho stays the system of record for money. Your portal becomes the face the customer sees. Your backend sits in the middle and does the talking.
One thing I'm strict about: the frontend never touches Zoho directly. No Zoho tokens in the browser, no API calls from client-side code. Zoho's own documentation says the same about keeping access tokens confidential, and it's not advice you want to ignore on something that exposes financial data. Everything goes through your backend.
So the flow looks like this:
Customer
↓
Your Portal (frontend)
↓
Your Backend ── OAuth 2.0 ──► Zoho Books
↓
Invoice data / PDF back to the customer
There are only a few moving parts, but one of them is quietly the hardest.
Connecting the business to Zoho. Using OAuth 2.0, the business authorizes your app to reach their Zoho Books data. A detail people skip here: only ask for the scopes you actually need. If your portal just reads invoices, request the invoice read scope, not full access to contacts, payments, credit notes and everything else. Smaller footprint, fewer things to worry about.
Matching each customer to the right Zoho record. This is the part everyone underestimates, and it's the one that matters most. When a user logs into your portal, your backend has to answer one question with total certainty: which Zoho customer is this person? Usually that means keeping a mapping in your own database your user's ID linked to their Zoho customer ID. Get this wrong and one customer can end up seeing another customer's invoices, which on a finance system is about the worst bug you can ship. So the login flow becomes: identify the user, look up their Zoho customer ID, and only ever fetch that customer's data.
Fetching the invoices. Once you know who they are, your backend calls Zoho, pulls their invoices, applies whatever business rules you have, and sends back something clean. The customer sees a simple list: invoice number, amount, status. All the complexity stays behind the curtain.
The download button. This is what the Gulf client cared about. Instead of pushing the customer into Zoho, the portal gives them a "Download" button, and the backend fetches the right invoice PDF for them. One rule I never break: the download endpoint has to verify that the invoice belongs to the logged-in customer. Never trust a URL like /download/invoice/12345 on its own. If someone changes that number, they should hit a wall, not someone else's invoice. Authorization happens on the server, every time.
Here's something that trips people up the moment they build for clients outside their own country: Zoho is not one single API domain.
Zoho Books runs across multiple data centers the US, Europe, India, Australia, Japan, Canada, and Saudi Arabia among them and each has its own API domain. Saudi Arabia is served from zohoapis.sa, India from zohoapis.in, and so on. A business's data lives in the data center tied to its account region.
If you hard-code one domain because it worked in testing, your integration will fail for a client in another region. The setup has to account for the organization's data center instead of assuming everyone is on the same one. For anyone building for Gulf clients, this isn't a footnote. It's the difference between the thing working and not working at all.
The most useful thing I can tell any business already running on Zoho is this: the answer is rarely "rip it out and build one big new system."
A business usually has a stack that already works Zoho Books, a website, maybe an ERP, a CRM, an internal database. Replacing all of that is expensive, risky, and usually unnecessary. The better move is to connect what's already there, so the customer gets one clean experience while your internal teams keep the tools they rely on.
A good integration can start small:
Customer Portal → Your Backend → Zoho Books
and grow, when you need it, into:
Customer Portal → Your Backend → Zoho Books + ERP + CRM + Internal Systems
The customer never has to know where any of it comes from. They log in, and everything is there.
If you already use Zoho Books and you want your customers (or your own team) to work with that data inside your own website, portal, ERP, or app, that's a build I've done and enjoy doing. It usually starts with a short conversation: tell me what you already use, what you want people to be able to do, and where the current process breaks. From there the integration gets designed around your actual workflow, instead of forcing your business to bend around the software.
I work with businesses remotely, including across the Middle East, so location isn't a blocker.