What Is a Webhook?

Key takeaways

• Polling every 5 minutes makes 288 requests a day. With 40 events a day, at most 40 of those polls carry news. So at least 248 of the 288 polls (86%) return nothing.
• Aurora’s documentation lists 32 webhook events. It allows 5 retries over about 24 hours and sets a 10-second response limit.
• In our model, a 1-hour outage on your side makes 41% of the affected events arrive more than an hour late. After 30 hours, 21% never arrive.
• Aurora and Salesforce both document duplicate and out-of-order deliveries. Your system must ignore repeats.
• Of the company pages cited, only HubSpot’s describes payload signatures. They are a SHA-256 hash in v1 and HMAC SHA-256 in the v3 version.

To compare the CRMs and design tools you might connect, see the best solar CRM and best solar design software lists.

Webhooks at a glance

Why webhooks matter for solar teams

A webhook lets one tool tell another the moment something changes. That cuts re-keying, speeds hand-offs and keeps the CRM current. The rules that act on an incoming webhook are covered in workflow automation.

Aurora’s documentation gives real uses. One is telling your team when a roof model is ready. Others are keeping a CRM in step with design details and starting post-sale work on a signed agreement. As an illustration, a sales rep who sees "signed" soon after signing could book a site survey sooner.

The risk is silent failure. A webhook that stops arriving looks like a quiet day. Before you build on one, learn how the company retries, signs and logs deliveries.

How a webhook works, and how it differs from polling

With polling, your system asks "anything new?" on a timer. With a webhook, the company sends a request to your URL only when an event happens.

1. You register an endpoint URL and pick events. You create Aurora subscriptions through the API or a dashboard. You create OpenSolar webhooks through its API.
2. An event happens, for example a project status change.
3. The company sends an HTTP request to your URL. It carries the event data or just identifiers.
4. Your endpoint answers fast with a success code. Slow work goes to a background queue.
5. If the answer is a failure or a timeout, the company tries again on its own schedule.

Polling is simple and recovers by itself after an outage. A webhook is faster and cheaper per event. But you must handle retries, repeats and missed events. Many teams use both. Webhooks give speed and a slow check-up poll is the safety net.

Figure 1. Polling buys speed with requests, while a webhook sends only the events, but a retry schedule leaves late or lost deliveries after a long outage.

Worked example: a 300-project installer

Take an installer with 300 active projects and 40 status events a day. These are illustrative numbers. Each figure follows from the formulas in the at-a-glance table and the retry schedule below.

The webhook row sends one request per event, so both request columns show 40. Network time is not modelled.

A changed-since list only works if the API offers one. Polling each project is the fallback, and it multiplies requests by the project count.

At a 5-minute interval, at most 40 of the 288 daily polls can carry news, so at least 86% return nothing. Those polls still average 2.5 minutes of delay.

Rate limits make this real. Enphase’s v4 plans page (October 2026) lists 1,000 hits a month for the free Watt plan. Polling one endpoint every 15 minutes for 30 days uses 2,880 hits. The fastest interval that fits is 43.2 minutes, if each poll is one hit. At 40 events a day, a webhook also sends fewer requests than list polling faster than every 36 minutes.

Polling versus webhook calculator

Retries, duplicates and order

A company retries a failed webhook on a fixed schedule. So the same event can arrive late, twice or out of order. Build your endpoint to expect all three.

The model covers one outage of your endpoint. It uses Aurora’s documented approximate retry intervals (30 seconds, 5 minutes, 30 minutes, 3 hours and 20 hours). Aurora’s page does not say whether each interval counts from the previous attempt or from the event. We assumed it counts from the previous failed attempt, so the last retry comes 23.6 hours after the event. The table below depends on that reading. The model assumes one outage a day, with events evenly spaced through it. Real outages are rarely this tidy. A long outage loses events.

The wait is long because the retry gaps grow. After a 1-hour outage, a 5-minute poll that restarts at recovery finds every change within 5 minutes. After 30 hours, 21% of affected events fall outside the retry window. Aurora says your account representative can resend a missed delivery within 30 days of the event.

If the endpoint fails independently on each attempt, retries work far better. At a 10% failure rate across 6 attempts, expected attempts are 1.11 and loss is 1 in a million. Outages are not independent. That is why the table above matters more.

Duplicates need an idempotent handler. That means handling the same event twice must change nothing. Aurora says duplicates are rare but possible, and ordering is not guaranteed. Its example is "signed" arriving before "viewed". Salesforce says a message usually arrives once but can arrive more than once. It advises checking notification IDs. If 1% of acknowledgements are lost, 40 events a day give 0.4 duplicates a day, or 146 a year.

How to secure a webhook endpoint

Anyone who learns your URL can post to it. So check that each request really came from the company. A signature is the strongest check. The company pages mostly document weaker ones.

1. Use HTTPS only. Aurora notes that an HTTPS URL encrypts the payload.
2. Verify a signature if the company offers one. HubSpot’s legacy-apps page describes an HMAC SHA-256 hash built with your app’s client secret. It comes in X-HubSpot-Signature-v3 with a timestamp. You should reject requests older than 5 minutes.
3. Otherwise check a shared token or basic-auth login. Aurora supports a header token, basic auth and a DNS allow list for aurorasolar.com. Its page describes no signature scheme.
4. Treat the payload as a prompt, not the truth. Aurora’s payloads carry identifiers and statuses. Fetch the record through the API before you act.
5. Log every delivery and compare the event ID with those already processed.

How solar software handles webhooks

Aurora, HubSpot and Salesforce give retry details, while Solar Proof says only that it may retry. Only HubSpot describes signatures. Ratings below follow each company’s own pages as read in October 2026.

Not stated: the company page we cite does not say. Partly: the page covers only part of the question (Solar Proof says it may retry, Salesforce documents outbound messages only). The notes below give the wording for each tool.

• Aurora Solar: 32 events listed. 5 retries over about 24 hours and a 10-second timeout.
• Aurora Solar (continued): Aurora disables a subscription if all retries fail within a 48-hour period. A subscription needs at least 50 attempts in that time to be considered. Security options are a header token, basic auth and a DNS allow list. One guide names the status event differently from the events page, so confirm it in the dashboard.
• OpenSolar: Created per organisation through the API. The queue endpoint shows attempts and next attempt time. The example sets an Authorization header. A support article dated 31 March 2026 says the API Access product is needed for the API and webhooks.
• Solar Proof: 7 event types, including contract_signed. "May retry". No count or schedule given. Must return 200 within 10 seconds. HTTPS, IP check, token in the URL. No signature described. The page tells you to expect the same webhook more than once.
• HubSpot Sales Hub: Webhooks API. Up to 10 retries over 24 hours, after a connection failure, a response slower than 5 seconds, or a 4xx or 5xx. v1 hash for CRM-object webhooks. V3 HMAC SHA-256 on the same page. The page does not say which webhook types use v3, so check the version header. Sources: HubSpot’s validating-requests, error-handling and retry changelog pages.
• Salesforce Sales Cloud: Outbound messages page only. Retry gap grows to a 2-hour maximum. Messages dropped after 24 hours. Security is not covered on the page read. It notes duplicates and out-of-order delivery. Other push features are not covered.
• Enlighten / Enphase App (not rated in the table): The v4 plans page lists a "Streaming API" for two paid plans with no detail. Rate limits apply to polling.

Zapier’s Catch Hook receives webhooks at a unique URL and returns 200, though its page documents no retries or signing. SolarEdge is not rated here, as its API documentation is not covered. To compare CRMs that send webhooks, see the best solar CRM. Design tools that send events are in the best solar design software list.

Questions to ask a company about webhooks

Ask these questions before you promise a customer an automatic hand-off. Get the answers in writing.

1. Which events exist, and does the payload carry full data or only identifiers?
2. How fast must my endpoint answer, and what counts as a failure?
3. How many retries, on what schedule, and for how long?
4. Is each request signed, or only token or IP checked? How do I rotate the secret?
5. Is there an event ID for de-duplication, and is ordering guaranteed?
6. Can missed events be replayed, and can I see a delivery log?
7. Is webhook access included in my plan, or a paid add-on?
8. When does a failing subscription get disabled, and how will I be told?

Common mistakes with webhooks

FAQs

Related terms

• API: the set of requests one program can make to another.
• Workflow automation: rules that act when a webhook arrives.
• Solar CRM: the customer system that most webhooks update.
• Integrations and integration marketplace: ready-made connections between tools.
• Data security and SOC 2: the controls a company can be audited against.

Sources

• Aurora Solar, Webhooks, Events and Be notified when projects are sold (checked October 2026).
• OpenSolar developer docs, Webhooks, Queue and Logs. API Access article (checked October 2026).
• Solar Proof, What are Webhooks? (checked October 2026).
• HubSpot, validating requests, error handling and retry logic changelog (checked October 2026).
• Salesforce, Understanding Notifications (outbound messaging) (checked October 2026).
• Zapier, Webhooks by Zapier and Solo, Setting up a webhook (checked October 2026).
• Enphase developer plans (v4) and Enphase developer portal (checked October 2026).

Last updated 30 October 2026. Next scheduled review: 30 January 2027.