Does RealGreen have webhooks? Real-time vs. nightly integration patterns

As of this writing, RealGreen does not offer a publicly documented webhook system: there is no supported way to have Service Assistant push an event (customer created, payment posted, service completed) to your endpoint the moment it happens, the way Stripe or Shopify do. Integrations get data out by asking: calling the API on a schedule, or replicating the database nightly. That sounds like a serious limitation. In our experience building RealGreen integrations, it mostly is not: when you sort real-world use cases by how fresh the data must be, very few need minutes, and the ones that do usually get their real-time signal from somewhere other than RealGreen anyway. Here is how we think it through, and the architecture we use.

What would webhooks buy you?

Event-driven integration means the source system announces changes instead of waiting to be polled. The virtues are efficiency (no wasted calls asking whether anything changed) and latency (seconds instead of hours). For a lawn company the tempting events are obvious: a new customer keyed in triggers the welcome sequence immediately; a payment posted cancels the dunning text scheduled for tonight; a cancel entered fires the save offer while the decision is fresh. Real value, and worth being clear-eyed about.

What does RealGreen actually offer?

A real REST API that can read and write the important objects, with keys metered by monthly call limits: the full capability map is in our RealGreen API guide. The metering shapes everything downstream. Polling the API every minute for changes across a 2,000-customer database burns the call budget on asking rather than doing, which is why serious integrations replicate the data on a nightly sync and work from the replica. If WorkWave ships documented webhooks someday, this calculus improves; until then, architect for what exists.

Polling vs. replication, plainly

Polling asks the API what changed since the last check: fresher data at higher call cost, with the interval as a dial between freshness and budget. Replication copies the database once nightly and answers every downstream question locally for free: segments, suppressions, reports, and audience syncs all hit the replica, never the API. Illustrative math, plug in your own: a marketing stack that checks live status before every send might make 15,000 metered calls a month; the same stack on a replica makes 30 sync runs. The replica is the workhorse. Polling is a scalpel you reserve for the few objects where hours are genuinely too slow.

Which jobs truly need real-time?

• Speed to lead. Minutes decide close rates on new inquiries, as the speed-to-quote data shows. But note where the lead is born: on your website, your phones, your LSA account: not inside RealGreen. Instant response gets wired at those front doors, no RealGreen webhook required. The full stack is in the five-minute rule.
• Payment-sensitive messaging. Dunning that texts a customer who paid this morning is the classic staleness injury. A same-day check on the narrow set of past-due accounts (a scalpel poll, or the payment processor's own notification) covers it.
• Missed-call response. Real-time by nature, and again the signal comes from the phone system, not from RealGreen.

Which jobs are fine on nightly data?

Almost everything else: campaign segments, renewal and win-back sequences, review requests, upsell audiences, direct-mail triggers, ad-platform audience syncs, dashboards, and every report an owner reads. A win-back that fires twelve hours after the cancel posts performs indistinguishably from one that fires in twelve seconds; a prepay letter does not care what happened this afternoon. Designing these to demand real-time freshness buys cost and fragility with no revenue attached, which is the quiet failure mode of over-engineered integrations.

Can you fake webhooks where they matter?

Mostly, yes, because the events you want in real time rarely originate inside RealGreen. Your form provider posts submissions instantly. Your phone and call-tracking platform fires events on missed calls and completed calls. Your chat widget hands off transcripts the moment they end. Your payment processor sends a notification the second a pay link clears. Every one of those systems does push events, so the practical move is to use them as your event bus and let RealGreen be the ledger that catches up on the nightly sync. A concrete example: a customer taps a texted pay link at 7pm and the processor's notification cancels tonight's dunning message within the minute, while the payment posts to the RealGreen account on its normal schedule. The customer experienced real-time; RealGreen never needed to push anything. The only events genuinely locked inside RealGreen are office actions: a cancel keyed in, a program edited, a note logged. Those you accept on a nightly delay or cover with a narrow poll, and it is worth noticing how short that list is compared to the anxiety it generates on sales calls for integration tools.

The pattern that works today

A hybrid. The nightly replica is the workhorse core. A thin real-time lane runs at the edges: instant response wired to forms, phones, and chat where leads are born, and a narrow same-day freshness check guarding payment-sensitive sends. Writes back into RealGreen (new leads, notes) go through the API deliberately, built to survive retries without creating duplicate records. Built this way, RealGreen connects to pretty much anything with an API, a Zapier connection, or a native connection: the sync does the heavy lifting, and the edges stay thin. That is the architecture behind our RealGreen API integration, and the full design rationale, including what to ask any vendor about sync health and monitoring, is laid out in batch versus real-time architecture.

The takeaway: RealGreen will not push events to you, and for nine automations out of ten it does not matter. Replicate nightly, poll narrowly where money is time-sensitive, and put your real-time engineering at the front doors where leads actually arrive.

Where to start

1. List your running and planned automations and label each one: needs minutes, needs same-day, fine with nightly.
2. Stand up (or buy) the nightly replica before building anything in the nightly column.
3. Wire instant lead response at the form, phone, and chat layer, independent of RealGreen.
4. Add a same-day payment check in front of any dunning or balance messaging.
5. Ask your integration vendor what happens when a sync fails overnight, and whether a human gets alerted.