Incentive API

Answer: An incentive API lets software request structured information about candidate solar incentives using project details such as location, utility, customer type and installation timing. The returned records can support research and proposals, but eligibility, funding and payment still require verification against current administrator rules. API access does not establish a customer’s tax entitlement or guarantee an award.

What the API exchanges

A request may include the project address, utility territory, system capacity and its AC/DC basis, ownership, residential or business use, equipment and expected installation date. The provider’s documentation determines which fields are supported. Missing or ambiguous inputs should produce an unresolved eligibility question, rather than a confident savings estimate.

Useful response fields include the program identifier, administrator, geography, incentive type, calculation basis, caps, eligibility conditions, application deadline, funding status, source URL and source-update timestamp. Distinguish that timestamp from the time your software fetched the record.

DSIRE’s official data-and-tools page describes data access options and points to API resources. Consult the current DSIRE API documentation for implementation details. This is an example of a data source, not a claim that SurgePV has access, that every program is covered or that an endpoint was tested here.

From candidate program to verified proposal

1. Match the project: confirm address, serving utility, customer class, ownership and equipment. A state match alone does not establish utility-program eligibility.
2. Read the administrator’s rules: confirm the current program version, open application window, eligible expenditure or installation dates and any preapproval requirement.
3. Check availability: distinguish a published program from one currently accepting applications with available funding. A cached API response is not a funding reservation.
4. Resolve interactions: determine whether rebates change another benefit’s calculation basis and whether programs can be combined. Refer tax questions to a qualified adviser.
5. Record a decision: retain the source, retrieval date, assumptions, reviewer and unresolved conditions. Label pending benefits separately from confirmed awards.
6. Refresh at milestones: recheck before issuing a proposal, accepting a contract and applying. Use the actual program deadlines rather than a universal refresh interval.

A practical record is: program ID / administrator rule URL / applicable date / project match / verification status / reviewer / next check. Keep historical proposal snapshots so later changes can be explained.

Incentive types are not interchangeable cash

An upfront rebate, nonrefundable tax credit, property-tax treatment and future certificate revenue have different conditions and timing. Do not subtract all of them from the amount due at installation or assume every customer can use the full value. Financial modeling should identify which cash flow receives each benefit and when.

U.S. federal residential example, checked September 30, 2026: the IRS Residential Clean Energy Credit page states that the credit is unavailable for property placed in service after December 31, 2025. Its historic 30% rate must not be applied automatically to a new 2026 residential installation. Business credits and other jurisdictions have separate rules; this residential cutoff does not decide their eligibility.

A capped rebate calculation

Suppose a hypothetical program pays $0.25 per eligible DC watt, capped at $1,500, and an 8 kW DC project meets its conditions:

8,000 W × $0.25/W = $2,000 before the cap

Candidate rebate = min($2,000, $1,500) = $1,500

The arithmetic establishes a conditional estimate. It does not prove eligibility, reserve funds or specify when payment arrives. Keep any application fee, tax interaction and payment timing separate. These numbers are invented calculation inputs, not a current program offer.

Integration controls that matter

Check authentication, licensing, supported territories, update policy, pagination and error handling in the chosen provider’s current documentation. Never expose secret credentials in a customer-facing page. A failed request or missing result should not silently become “no incentives available.” Preserve the error and offer manual review.

Use explicit program identifiers to prevent duplicate awards. Store units and dates with values, and keep calculation rules separate from descriptive text. Reconcile a sample response against the administrator’s source before relying on automated proposals. Verify any claimed solar-software integration with an actual supported workflow and plan; a general API definition proves no product entitlement.

For related concepts, see the local incentives database and investment tax credit, while checking their current jurisdiction and dates.

Frequently asked questions

Does an incentive API guarantee eligibility?

No. It returns information that must be matched to the project and checked against current administrator rules and, where relevant, tax advice.

Is every response real-time?

No universal update frequency applies. Check the provider’s policy and source timestamp; retrieval time alone does not establish freshness.

Can all benefits be deducted from the upfront price?

No. Eligibility, calculation interactions, payment timing and the customer’s ability to use a benefit must be modeled separately.

Does SurgePV automatically include a particular API?

Confirm current integrations, access and plan availability directly. This definition does not establish a provider agreement or implemented connection.