I've spent the last few months building a solar proposal tool for a mid-size installer, and the Google Solar API fundamentally changed how we approached the project. What used to require a truck roll, a ladder, and an hour on somebody's roof now takes a single API call and about 400 milliseconds. That's not hyperbole -- it's what I measured in production.

The Solar API isn't just a novelty. It's a technical shift in how solar companies qualify leads, design systems, and close deals. If you're building software in the solar space -- or considering it -- this is the API you need to understand deeply. Let me walk you through everything I've learned.

What Is the Google Solar API?

The Google Solar API is part of Google Maps Platform's Environment APIs. It started life as Project Sunroof back in 2015 -- a consumer-facing tool that estimated solar savings for homeowners. Google spent years working with solar industry players to turn that into a proper developer API, and it launched publicly in 2023.

Here's what it actually does: it takes an address or lat/lng coordinate, cross-references it against Google's aerial imagery and geospatial data, and returns detailed information about the building's rooftop -- its geometry, slope, orientation, shading patterns, and estimated solar energy production. All from satellite and aerial imagery. No site visit required.

As of early 2025, the API covers over 320 million buildings across 40+ countries. The coverage keeps expanding, with recent additions including Japan, the Philippines, Mexico, and additional European countries. The US has the densest coverage, but it's genuinely global now.

The underlying tech is fascinating. Google combines high-resolution aerial imagery with machine learning models to generate Digital Surface Models (DSMs). These 3D representations capture not just the roof but surrounding trees, neighboring buildings, and anything else that might cast shadows. They then run solar flux calculations against these models using historical weather data to produce hour-by-hour shading and irradiance estimates.

The Three Endpoints Explained

The API exposes three distinct endpoints. Each serves a different purpose, and you'll likely use all three in a production solar application.

buildingInsights

This is your workhorse endpoint. Send it a location, and it returns structured JSON with everything you need for a quick solar assessment:

  • Building location and bounding box
  • Roof segment count, pitch, azimuth, and area
  • Maximum panel count per segment
  • Annual sunshine hours
  • Estimated energy production (kWh/year)
  • Financial analysis (with configurable utility rates)
  • Carbon offset estimates
GET https://solar.googleapis.com/v1/buildingInsights:findClosest?
  location.latitude=37.4450&
  location.longitude=-122.1390&
  requiredQuality=HIGH&
  key=YOUR_API_KEY

The response is dense. You'll get back a solarPotential object that includes roofSegmentStats -- an array where each element represents a distinct plane on the roof. Each segment has its own pitch angle, azimuth, area in square meters, and panel placement information.

What surprised me most: it also returns solarPanelConfigs -- an array of possible configurations ranked by energy production. Each config specifies exactly how many panels to place on each roof segment and the corresponding annual energy output. Google's doing the layout optimization for you.

dataLayers

This endpoint returns URLs to raw raster data layers for a given area. It's designed for developers who want to do their own analysis or build visual overlays:

GET https://solar.googleapis.com/v1/dataLayers:get?
  location.latitude=37.4450&
  location.longitude=-122.1390&
  radiusMeters=100&
  view=FULL_LAYERS&
  requiredQuality=HIGH&
  key=YOUR_API_KEY

The response includes URLs for:

  • Digital Surface Model (DSM)
  • RGB aerial imagery
  • Annual flux map
  • Monthly flux maps (12 separate layers)
  • Hourly shade maps (aggregated into 12 monthly maps)
  • Mask layer (which pixels are rooftop)

These are GeoTIFF files. They're not small -- you'll need to handle them thoughtfully.

geoTiff

The third endpoint fetches the actual raster files referenced by dataLayers. You take the URLs from the previous response and hit this endpoint to download the GeoTIFF data.

GET https://solar.googleapis.com/v1/geoTiff:get?
  id=GEOTIFF_ID&
  key=YOUR_API_KEY

These files contain encoded solar information that you can process with libraries like geotiff.js on the client or GDAL on the server. The flux maps are particularly useful -- they encode solar irradiance values in kWh/kW/year for each pixel.

Real-World Data: What You Actually Get Back

Let me show you a trimmed version of a real buildingInsights response so you know what you're working with:

{
  "name": "buildings/...",
  "center": { "latitude": 37.445, "longitude": -122.139 },
  "boundingBox": { ... },
  "imageryDate": { "year": 2023, "month": 8, "day": 15 },
  "imageryQuality": "HIGH",
  "solarPotential": {
    "maxArrayPanelsCount": 42,
    "maxArrayAreaMeters2": 73.5,
    "maxSunshineHoursPerYear": 1825.4,
    "carbonOffsetFactorKgPerMwh": 428.9,
    "wholeRoofStats": {
      "areaMeters2": 142.8,
      "sunshineQuantiles": [812.3, 1124.5, ...],
      "groundAreaMeters2": 118.2
    },
    "roofSegmentStats": [
      {
        "pitchDegrees": 22.5,
        "azimuthDegrees": 180.3,
        "areaMeters2": 58.2,
        "panelsCount": 22,
        "stats": {
          "sunshineQuantiles": [1650.2, 1720.1, ...]
        }
      }
    ],
    "solarPanelConfigs": [
      {
        "panelsCount": 42,
        "yearlyEnergyDcKwh": 15840.5,
        "roofSegmentSummaries": [
          { "segmentIndex": 0, "panelsCount": 22 },
          { "segmentIndex": 1, "panelsCount": 20 }
        ]
      }
    ],
    "panelCapacityWatts": 400,
    "panelHeightMeters": 1.879,
    "panelWidthMeters": 1.045,
    "panelLifetimeYears": 20
  }
}

The imageryQuality field is important. Google provides two quality tiers: HIGH (derived from high-resolution aerial imagery) and MEDIUM (derived from satellite imagery with ML enhancement). High quality data uses sub-meter resolution imagery. Medium quality is still useful but less precise for shadow analysis.

You can control which quality you accept with the requiredQuality parameter. If you set it to HIGH and the building only has MEDIUM coverage, you'll get an error. For most production apps, I'd recommend accepting both and displaying a confidence indicator to users.

Coverage, Quality Tiers, and Limitations

Coverage is not uniform, and understanding the gaps matters.

High-quality data is concentrated in the US (most states now have solid coverage), parts of Western Europe (Germany, UK, France, Spain, Italy), Japan, and Australia. Medium-quality coverage, which Google has been aggressively expanding using satellite imagery and ML models, now reaches most of the Americas, Europe, and parts of Asia-Pacific.

There are real limitations to be aware of:

  • Imagery freshness: The imageryDate field tells you when the aerial/satellite image was captured. I've seen dates ranging from 2019 to 2024. If a roof was replaced or trees were removed after the capture date, the analysis will be wrong.
  • Flat roof complexity: The API handles sloped residential roofs well. Large flat commercial roofs with mechanical equipment, HVAC units, and complex parapet walls? Less reliable.
  • New construction: Buildings that didn't exist when imagery was captured won't appear. This sounds obvious, but it bites people building lead-gen tools for new developments.
  • Tree growth: Shadow analysis reflects tree canopy at capture time. Trees grow. A three-year-old image might underestimate current shading.
  • Panel specifications are fixed: The API uses reference panels (currently 400W, 1.879m × 1.045m) reflecting 2024 industry standards. You can't customize panel dimensions in the request.

Pricing Breakdown for 2025

Google updated the Solar API pricing structure, and it's worth understanding the tiers carefully. Here's what you're looking at as of 2025:

Endpoint Monthly Free Tier 0-100K Requests 100K+ Requests
buildingInsights Up to $300 credit ~$10 per 1,000 calls Volume pricing available
dataLayers Up to $300 credit ~$50 per 1,000 calls Volume pricing available
geoTiff Included with dataLayers Counted per fetch -

The $300 monthly credit applies across all Google Maps Platform APIs, not just Solar. If you're already using Maps, Geocoding, or Places APIs, your Solar usage eats into the same pool.

For a typical solar installer's website generating 500 leads per month, you're looking at roughly 500 buildingInsights calls (for initial assessment) plus maybe 100 dataLayers calls (for detailed proposals). That's well within the free tier for many businesses.

But here's the catch: the per-minute quota starts at 60 queries per minute per endpoint. If you're building a batch processing tool that scans entire neighborhoods, you'll hit rate limits fast. You can request quota increases through the Google Cloud Console, but plan for this early.

Building a Solar Roof Assessment Tool

Let me walk through the architecture of a real solar assessment tool. This is close to what we built for a client -- a Next.js application that lets homeowners enter their address and get an instant solar estimate.

The Frontend Flow

The user enters an address. We use Google's Places Autocomplete to handle address input (you need this anyway since the Solar API needs coordinates, not street addresses). Once we have lat/lng from geocoding, we hit our backend API route.

// app/api/solar-assessment/route.ts
import { NextResponse } from 'next/server';

export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const lat = searchParams.get('lat');
  const lng = searchParams.get('lng');

  if (!lat || !lng) {
    return NextResponse.json({ error: 'Missing coordinates' }, { status: 400 });
  }

  const response = await fetch(
    `https://solar.googleapis.com/v1/buildingInsights:findClosest?` +
    `location.latitude=${lat}&location.longitude=${lng}` +
    `&requiredQuality=HIGH` +
    `&key=${process.env.GOOGLE_SOLAR_API_KEY}`
  );

  if (!response.ok) {
    // Fall back to MEDIUM quality if HIGH isn't available
    const fallback = await fetch(
      `https://solar.googleapis.com/v1/buildingInsights:findClosest?` +
      `location.latitude=${lat}&location.longitude=${lng}` +
      `&requiredQuality=MEDIUM` +
      `&key=${process.env.GOOGLE_SOLAR_API_KEY}`
    );
    
    if (!fallback.ok) {
      return NextResponse.json(
        { error: 'No solar data available for this location' },
        { status: 404 }
      );
    }
    
    return NextResponse.json(await fallback.json());
  }

  return NextResponse.json(await response.json());
}

Never expose your API key on the client. Always proxy through your backend. This is basic stuff, but I've seen production solar apps with keys in the frontend bundle.

Processing the Response

The raw API response needs transformation before it's useful to end users. Here's how we process it:

interface SolarEstimate {
  maxPanels: number;
  roofAreaSqFt: number;
  annualProductionKwh: number;
  monthlyProductionKwh: number;
  estimatedAnnualSavings: number;
  co2OffsetLbs: number;
  roofSegments: RoofSegment[];
  imageryQuality: 'HIGH' | 'MEDIUM';
  imageryDate: string;
}

function processBuilding(data: BuildingInsightsResponse): SolarEstimate {
  const solar = data.solarPotential;
  const bestConfig = solar.solarPanelConfigs[
    solar.solarPanelConfigs.length - 1
  ]; // max panels config

  const annualKwh = bestConfig.yearlyEnergyDcKwh * 0.85; // 85% DC-to-AC derate
  const electricityRate = 0.16; // $/kWh -- should be localized

  return {
    maxPanels: solar.maxArrayPanelsCount,
    roofAreaSqFt: solar.maxArrayAreaMeters2 * 10.764,
    annualProductionKwh: Math.round(annualKwh),
    monthlyProductionKwh: Math.round(annualKwh / 12),
    estimatedAnnualSavings: Math.round(annualKwh * electricityRate),
    co2OffsetLbs: Math.round(
      (annualKwh / 1000) * solar.carbonOffsetFactorKgPerMwh * 2.205
    ),
    roofSegments: solar.roofSegmentStats.map(transformSegment),
    imageryQuality: data.imageryQuality,
    imageryDate: formatImageryDate(data.imageryDate),
  };
}

Notice the 0.85 DC-to-AC derate factor. The API returns DC production estimates. Real-world AC output is always lower due to inverter efficiency, wiring losses, temperature derating, and soiling. Industry standard derate factors range from 0.80 to 0.88. Don't skip this step -- presenting DC numbers to customers is a fast way to lose credibility.

Architecture Patterns for Solar Web Apps

For a solar installer's website that needs instant quotes, here's the architecture I'd recommend:

Next.js or Astro Frontend

Both work well. If you need a highly interactive proposal builder with real-time panel placement, Next.js is the better fit -- its server components and API routes make the Google Solar API integration clean. If the assessment is mostly a lead-gen landing page with static content around it, Astro's island architecture keeps the page fast and ships less JavaScript.

Headless CMS for Content

Solar content changes constantly -- incentive programs expire, utility rates shift, new panel models launch. Using a headless CMS to manage the non-API content (educational articles, testimonials, service area pages) lets the marketing team update without developer involvement.

Caching Layer

This is critical. Solar data for a given building doesn't change frequently -- Google updates imagery periodically, not daily. Cache buildingInsights responses for at least 24-72 hours. We use Redis with a key pattern like solar:${lat}:${lng}:${quality} and a 48-hour TTL. This alone cut our API costs by 60% because repeat visitors and internal team reviews hit cache instead of Google.

Background Processing for Data Layers

The dataLayers endpoint returns GeoTIFF URLs that are expensive to fetch and process. Don't do this synchronously in a user request. Queue it, process it in the background, and notify the user when their detailed analysis is ready. We use a simple job queue -- BullMQ works great with Next.js.

How Installers Are Using This in Production

From what I've seen working with solar companies, there are three primary use cases:

Instant online quotes: Homeowner enters address, gets an estimated system size and savings in under 5 seconds. This is the killer use case. Companies using this report 30-40% higher lead conversion compared to "fill out a form and we'll call you" approaches.

Sales team qualification: Before a sales rep drives to a property, the team checks the Solar API data. If the roof is heavily shaded, too small, or facing north, they know before burning an hour of windshield time. One installer told me this saved them roughly 15 hours per week in wasted site visits.

Neighborhood prospecting: Using batch processing against the buildingInsights endpoint, companies identify the best solar candidates in a given area. Sort by annual production potential, filter by minimum roof area, and you've got a targeted door-knocking list.

Comparison: Google Solar API vs. Manual Assessment vs. Alternatives

Factor Google Solar API Manual Site Visit Aurora Solar EagleView
Time to assessment < 5 seconds 1-3 hours 5-15 minutes 1-3 days
Cost per assessment $0.01-0.05 $150-400 $25-50/design $15-40/report
Accuracy (energy est.) ±10-15% ±5-8% ±5-10% ±8-12%
Requires API integration Yes No Yes (SaaS) Yes (SaaS)
Covers new construction No Yes No No
Shadow analysis Hourly, annual Visual only Hourly, annual Monthly
3D modeling Raw DSM data N/A Full 3D Full 3D
Global coverage 40+ countries Unlimited US focused US focused

The accuracy gap is real. The Solar API is a pre-qualification tool, not a replacement for engineering design. Smart installers use it for the top of the funnel (lead gen, instant quotes, qualification) and then do proper site assessments for the deals that progress.

That said, for a custom web application where you need full control over the user experience and data flow, the Solar API is unmatched in terms of raw data access at a low price point. The alternatives are mostly SaaS platforms that own the UX.

Performance Optimization and Caching Strategies

A few things I learned the hard way:

Geocoding adds latency. The Solar API needs lat/lng coordinates. If you're starting from an address, you need to geocode first. That's two API calls in sequence. Use Google's Places API getPlace() with the location field to get coordinates in one call instead of a separate Geocoding API request.

GeoTIFF files are heavy. A full dataLayers response for a 100-meter radius can result in 10-20 MB of raster data across all layers. Don't fetch all layers if you don't need them. Use the view parameter -- IMAGERY_AND_ANNUAL_FLUX_LAYERS is usually sufficient for proposal tools and skips the monthly/hourly data.

Client-side GeoTIFF rendering is possible but painful. Libraries like geotiff.js and plotty can render flux maps directly in the browser, overlaid on a Google Map. It works, but parsing large GeoTIFFs on mobile devices is slow. We moved to server-side rendering of the map overlays as PNG tiles, which made mobile performance significantly better.

Batch processing needs throttling. At 60 QPM default quota, processing 10,000 buildings takes nearly 3 hours. Build your batch pipeline with exponential backoff and respect 429 responses. Request quota increases early -- Google's been reasonable about granting them for legitimate solar use cases.

If you need help building a production-grade solar assessment platform, our team has deep experience with these exact integrations. We've built several headless solar web apps -- check our pricing page for project estimates.

FAQ

How accurate is the Google Solar API for estimating solar panel output?

In my testing against actual installed systems, the API's energy estimates are typically within 10-15% of real-world production when you apply a proper DC-to-AC derate factor (0.82-0.88). High-quality imagery areas tend to be more accurate. The main sources of error are outdated imagery (trees that have grown, roof modifications) and localized weather patterns that differ from the historical data Google uses.

How much does the Google Solar API cost per request?

The buildingInsights endpoint costs roughly $0.01 per request after you exhaust the $300 monthly Google Maps Platform credit. The dataLayers endpoint is more expensive at approximately $0.05 per request. For a typical solar installer processing 500-1,000 leads per month, costs usually stay within the free tier. Volume pricing is available for larger deployments.

Does the Google Solar API work outside the United States?

Yes. As of 2025, the API covers over 320 million buildings in 40+ countries. Coverage includes most of Western Europe, Japan, Australia, Mexico, the Philippines, and parts of South America. Quality varies by region -- the US and Western Europe generally have high-quality aerial imagery, while newer coverage areas often use medium-quality satellite-derived data.

Can I use the Google Solar API to design a complete solar panel layout?

Partially. The API provides optimized panel configurations through the solarPanelConfigs array, which tells you how many panels to place on each roof segment. However, it uses fixed reference panel dimensions (currently 400W, 1.879m × 1.045m as of 2025) and doesn't support custom panel models, microinverter placement, or electrical string design. For detailed engineering design, you'll still need tools like Aurora Solar or OpenSolar.

What's the difference between HIGH and MEDIUM imagery quality in the Solar API?

HIGH quality data comes from aerial imagery (typically captured by aircraft) with sub-meter resolution. It produces more accurate 3D roof models and shadow analysis. MEDIUM quality uses satellite imagery enhanced with machine learning. It's less precise for complex roof geometries and fine-grained shadow analysis but still useful for initial lead qualification and energy estimation. You can specify which quality level you require using the requiredQuality parameter, or use exactQualityRequired for strict matching.

How often does Google update the Solar API imagery?

Google doesn't publish a fixed update schedule. In practice, I've seen imagery dates ranging from 2019 to 2024 across different locations. The imageryDate field in the API response tells you exactly when the source imagery was captured. For production applications, always display this date to users -- it's important context for the accuracy of the assessment.

Can I overlay Solar API data on a Google Map in my web application?

Absolutely, and this is one of the most compelling use cases. The dataLayers endpoint returns GeoTIFF rasters that include flux maps and DSM data. You can process these into map tiles and overlay them on Google Maps using ImageMapType or convert them to Canvas overlays. Libraries like geotiff.js handle the client-side parsing, though server-side pre-processing into PNG tiles performs better on mobile.

What programming languages and frameworks work best with the Google Solar API?

The API is a standard REST API, so it works with any language that can make HTTP requests. For web applications, Next.js and Astro are excellent choices for building solar assessment tools -- Next.js for interactive proposal builders and Astro for content-heavy solar marketing sites. On the backend, Node.js and Python are the most common. Python is particularly useful if you're processing GeoTIFF data, since GDAL and rasterio have mature Python bindings.