APIs and webhooks, explained in plain English

Every tool in your business can talk. Your proposal software knows the moment a customer opens a quote. Your job management platform knows when a job is finished. Your lead provider knows a new enquiry exists seconds after the form is submitted. The problem is that in most trade businesses, none of these tools are talking to each other - so a human ferries the information between them, one copy-paste at a time.

APIs and webhooks are the two mechanisms that fix this, and they are worth understanding even if you never intend to touch a line of code - because they are the difference between software that works alongside your business and software that works together as one system. Here is the whole topic in plain English, with real examples from the tools Australian installers and trades actually run.

An API is ordering at the counter

API stands for application programming interface, which explains nothing. Here is what it actually is: a counter where one piece of software can ask another piece of software for something, and get a structured answer back.

Your CRM walks up to OpenSolar's counter and asks, "what is the status of the proposal for 14 Fairview Street?" OpenSolar answers: sent Tuesday, viewed twice, not yet signed. Your CRM asks Xero, "has invoice 2041 been paid?" Xero answers: yes, Thursday. Every modern platform you use - OpenSolar, Pylon, Simpro, AroFlo, ServiceM8, Stripe, Xero - has a counter like this. The API is simply the rules of the conversation: what you can ask for, how to prove you are allowed to ask, and what shape the answer comes back in.

APIs are how software asks. But asking has a built-in weakness: you have to know when to ask.

A webhook is the doorbell

Imagine wanting to know whether a parcel has arrived, with no doorbell. Your only option is walking to the front door every five minutes to check. In software this is called polling, and it is exactly as wasteful as it sounds - thousands of "anything yet?" requests, almost all answered with "no", while the one event you care about still gets noticed minutes late.

A webhook is the doorbell. Instead of your CRM asking OpenSolar every few minutes whether a proposal has been viewed, OpenSolar simply rings your system the instant it happens: "proposal viewed, 7:42pm, second time." The event pushes to you, immediately, with no wasted checking. Webhooks are how software tells.

Why events beat checking, in dollars

This is not a technical nicety - it is where the money is. Most enquiries go cold within hours, and a viewed-but-unsigned proposal is at its warmest the evening it was opened. A system that polls every hour, or worse, waits for a human to log in and look, acts on yesterday's signals. A system built on webhooks acts on this minute's.

That is the entire mechanical basis of speed to lead and of proposal follow-up that actually converts: the event arrives instantly, and an action fires instantly. No mechanism, no speed.

What real chains look like

Single connections are useful. Chains are where a business changes shape. Three we build constantly:

• Lead to booked call. A SolarQuotes enquiry hits your lead API connection, lands in the pipeline tagged by source, and Piper opens a conversation within seconds - at 9pm on a Sunday, same as 9am on a Tuesday.
• Quote to conversation. OpenSolar fires a webhook the moment a proposal is viewed. The CRM logs it, and Andy follows up referencing the actual site-visit notes - while the customer is still thinking about it. The full playbook is in how to automate proposal follow-up.
• Sale to everything else. A signed proposal triggers the chain: job created in Simpro, AroFlo or ServiceM8, pipeline stage moved, invoice raised, and a review request queued for after installation. One event, five systems updated, zero re-typing.

What separates integrations that last from ones that quietly die

Anyone can connect two tools on a sunny day. The engineering is in what happens on the bad days, and this is where cheap integrations fail silently:

• Retries. Connections hiccup. A serious integration retries until the update lands; a flimsy one drops the data and nobody notices until a customer asks why their job vanished.
• Authentication that maintains itself. API keys expire and passwords change. Handled properly, credentials are stored encrypted and refreshed without drama.
• Logging. When someone asks "why did this record change?", structured logs give a traceable answer instead of a shrug.
• Field mapping that matches how you actually work. Your "system size" needs to land in the right field every time, not in a notes column someone has to clean up.

These four principles - event-driven, retry-first, encrypted credentials, audit-ready logging - are the foundations our own integration layer is built on. It is unglamorous plumbing, and it is the reason "one entry, everywhere updated" holds true at 2am, not just in the demo.

Build it yourself, or have it built?

Honest answer: the popular no-code connectors are genuinely fine for simple, one-way, low-volume jobs - a form submission creating a spreadsheet row does not need custom engineering. Where they strain is exactly where trade businesses live: two-way sync between a CRM and job management, proposal events that must never be missed, and chains where one failure breaks four downstream steps.

That is the point where integration stops being a settings page and becomes engineering - and it is precisely the work our team does, whether as part of the Solar AI-Q platform with its included integrations, or as custom API and webhook builds for businesses with tools and workflows outside the usual stack.

You do not need to write a webhook handler to benefit from understanding this. You just need to ask one question of every tool you pay for: when something important happens in here, who finds out, and how fast? If the answer is "whoever checks next", there is money leaking through that gap - and now you know the names of the two mechanisms that close it.