Privacy policy

Version: 1.7
Last updated: October 29, 2026

The current version is at https://solar360.io/privacy/

This privacy policy tells how Solar 360, LLC collects, uses, shares, and protects personal information. It applies to:

our website at solar360.io (the Site)
the Solar 360 app on the web and on phones, and its API (the Service)
email with our team

In this policy, Solar 360, we, us, and our mean Solar 360, LLC. You means the person who reads this policy. Personal information means information that identifies a person, or that relates to a person and can reasonably link to that person.

1. Who we are

Solar 360, LLC is a New Hampshire limited liability company. It is a subsidiary of Aeon Technologies Global, LLC, also a New Hampshire limited liability company. Aeon Technologies Global, LLC publishes the Solar 360 apps for iPhone and Android in the app stores. Solar 360, LLC provides the Service in these apps.

Address: Solar 360, LLC, 31 Hawk Dr, Salem, NH 03079, United States
Email: support@solar360.io

Send privacy questions and privacy requests to this email address.

2. Our two roles

The Service is a work tool for solar sales companies in the United States. We call each company that subscribes a Customer. Each Customer has one Organization in the Service. The people who use the Service in an Organization are Users: the staff of the Customer, its contractors, and the homeowners that it invites. The Owner is the User who manages the subscription of an Organization.

We have two different roles under the privacy laws of US states (US State Privacy Laws). Examples of these laws are the California Consumer Privacy Act and the consumer privacy laws of Colorado, Connecticut, New Hampshire, Texas, and Virginia.

We are the controller of Account Data, Billing Data, and Site data. Section 3 describes this information. We decide why and how we use it. This policy tells what we do with it.
We are a processor of Customer Data. Under US State Privacy Laws, we are a “service provider” or a “processor” for this data. Customer Data is the information that a Customer and its Users put into the Service, and the records that the Service makes from it. Examples are leads, homeowners, appointments, notes, files, photos, and messages.

The Customer decides why and how the Service uses its Customer Data. We use Customer Data only to give the Service to that Customer. Our Data Processing Addendum states our duties as a processor.

If a solar company that uses Solar 360 has information about you, that company controls the information. Its own privacy policy applies. Send your requests to that company. Section 11 tells how we help.

Each Customer is responsible for a lawful basis to collect information about homeowners and to contact them. This includes the laws about door-to-door sales, telephone calls, text messages, and email.

3. Information we collect

Account Data

When a person creates an account or accepts an invitation, we collect:

the name and the email address
the password, which we store only as a one-way hash. Nobody can read the password from the hash.
the Organization, the role, the team, and the status of the User in that Organization
the two-factor settings, if the User turns on two-factor authentication. We store the authenticator (TOTP) secret and the backup codes encrypted.

We also keep records about the security of each account:

Sessions. Each session has a token, the IP address, the browser name (user agent), and the times of start and expiry. In the Solar 360 apps for iPhone and Android, the user agent names the app, its build, and the system version of the phone.
Failed sign-ins. After a failed sign-in, we keep a hash of the email address for 15 minutes to stop password guessing. This record has no IP address and no password.
Server logs. Our servers write one line for each request: the method, the path, the status, the duration, and the ids of the Organization and the User. The logs do not keep the content of requests.
Error reports and performance data. When the app or our servers have an error, a report goes to Sentry, our error monitoring provider. Our servers also send Sentry performance data: the timings of some requests and jobs. A report holds technical data: the error, the path, the browser name, the app version, and the ids of the membership and the organization. Before a report leaves the app, we remove passwords, tokens, cookies, request bodies, and email addresses. We set Sentry so that it does not store IP addresses.
- In the app for iPhone, a report also goes to Sentry when the app crashes. A report of the app also holds technical facts of the phone, for example the model, the iOS version, the language, and the free memory. It holds a random id of the installation of the app, and the recent steps in the app before the error. Examples of these steps are the screens that opened and the requests to our servers, without their content. The app sends no screenshots and no recordings of the screen.
- In the app for Android, a crash report also goes to Sentry, in a separate Sentry project. It holds the same kinds of data as a report of the app for iPhone, with the Android version in place of the iOS version. The app sends no screenshots, no view hierarchy, and no reports of native (NDK) crashes.

Billing Data

The Owner pays through Stripe. Stripe collects the card details. We never receive or store card numbers. We receive and keep:

the billing email address
the card brand and the last four digits of the card number
the plan, the number of seats, the subscription status, the invoices, and the payment status
the tax status of the Customer

Stripe also collects the billing address, the business name, and the tax ID, if the Owner gives one. We can see this information in Stripe.

Customer Data

Customers and their Users put this information into the Service, or the Service makes it for them:

Leads and homeowners: names, phone numbers, email addresses, home addresses, notes, and the status of each lead
Knocks: the result of each knock at a door, a note, the time, and the location of the User (see the next part)
Appointments: the time, the people, the status, and the result. A homeowner can confirm an appointment or ask for a new time through a link in an email.
Deals: the property, the system size, the price, the financing, the stage, the dates, and the people on the deal
Files and photos: contracts, designs, permits, and photos of the work, with the metadata that the device puts in each file (see the next part)
Messages: chat messages between Users, and messages between the team and a homeowner
Work records of Users: teams, tasks, quotas, reports, contests, points, training results, commissions, and payroll
Contractor records: jobs, dates, costs, and crew notes

Location

When a User logs a knock, the Service asks the phone for its GPS position. The Service stores the position, its accuracy, and the distance from the User to the door of the property. The Customer uses these “door checks” to confirm that a knock happened at the door.

The browser asks the User for permission first. In the Solar 360 app for iPhone, iOS asks for it. In the app for Android, Android asks for it. If the User does not give permission, the Service stores the knock without a position.
The app for iPhone asks for the position only while the User uses the app. It has no permission for the position in the background. The app for Android asks for the precise and the approximate position for the same uses, only while the app shows on the screen. It has no permission for the position in the background. If the User allows only an approximate position, the Service stores that position and its accuracy.
The map also uses the position of the phone to show the User where they are. This position stays on the phone. We do not store it.
The Service does not record the position of a User between knocks, or when the app is closed.
A photo or a file that a User uploads can hold metadata from the device that made it: for example the GPS position, the date and time, and the camera model. The Service keeps each file as the User uploaded it, with its metadata. The Customer uses it, for example, to confirm where and when a photo of an install was taken. Each User in the Customer’s organization who can open the file can read its metadata. To upload photos without a position, a User can turn off location for the camera in the settings of the phone.
In the app for iPhone, the User picks each photo in the photo picker of iOS. The app gets only the photos that the User picks. It cannot read the rest of the photo library.
iOS asks the User for permission before the app uses the camera. A photo that the User takes with the camera of the app holds no GPS position.
If the User saves an image from the app to the photo library, iOS asks for permission to add it. The app does not read the library.
The app for Android has no permission for the camera and no permission for the storage of the phone. The User picks each photo in the photo picker of Android, and each file in the file picker of Android. To take a photo, the app opens the camera app of the phone through Android. The app gets only the photos and the files that the User picks or takes.

The location of a knock and the metadata of an uploaded file are Customer Data. The Customer controls them.

Public property records

The map of the Service shows property records from public government sources, such as the parcel maps and the assessor records of a state or a town. These records can include the address, the parcel outline, the name and the mailing address of the owner, facts about the building, and building permits. We collect these records from the public sources. We show them only to the Users of Customers that have access to that town in the Service.

Calendar data

If a User connects a Google or a Microsoft calendar, we collect the data that section 6 describes.

Information from the Site and from email

The Site has no cookies, no analytics, and no tracking. Our hosting provider (Amazon CloudFront) uses the IP address of each visit to send the page. We do not keep logs of visits to the Site. The Site keeps one setting in your browser: the theme that you choose (see section 5).

The Site has one form: the contact form. “Book a demo” opens it, and the page solar360.io/contact has the same form. When you send it, we collect:

the name of your company
your name
your email address
your phone number

We use these details to answer your request and to arrange a demo. A small program that we run at Amazon Web Services (AWS Lambda) receives the form. It adds the time and the address of the page, and sends all of it to our team as one email through Amazon Simple Email Service. The email goes to our contact inbox, hello@solar360.io, which Google Workspace hosts. The people of our team who answer these requests read it.

The program keeps no copy of the form. Its logs record each send, each refused form, and each error, but not the details of the form or your IP address. We keep these logs for 30 days. You can ask us to see, correct, or delete the details that you sent, as section 11 describes.

The contact form uses Cloudflare Turnstile, a check that tells people from bots. The Site loads Turnstile only for the form: when you open “Book a demo”, or when you open the page solar360.io/contact. The other pages of the Site do not load it. Turnstile runs small tests in your browser. It sends Cloudflare your IP address, the browser name (user agent), technical data about your browser and its connection, and the address of the Site. Turnstile does not read or send the details that you type into the form. Usually you see nothing. Sometimes Turnstile asks you to check a box. Turnstile then gives the form a token that works once. The program sends the token to Cloudflare, and it sends your request to our team only when Cloudflare confirms the token.

Cloudflare says that it uses this data only to detect and block bots, and to improve its bot detection. It also says that it does not use the data to identify, profile, or target a person. For the check of our form, Cloudflare processes the data for us. To improve its bot detection, Cloudflare is a controller of the data. The Cloudflare Turnstile Privacy Addendum gives the details.

If you send us an email, we keep the email, your email address, and our reply, so that we can help you.

Information on the device

The app keeps some information in the browser of the device:

the sign-in cookie (see section 5)
settings, such as the theme and the map view
recent searches
the actions that wait for a network connection, for example the knocks that a User logs without signal

If a User turns on push notifications, the browser gives us a push address (an endpoint and its keys) and the browser name.

The Solar 360 app for iPhone keeps no cookies. It keeps this information on the phone:

the session token, in the Keychain of the phone. iOS does not copy this item to iCloud or to another phone. The app removes the token at sign-out. If iOS keeps the token after the User deletes the app, the app removes it at the next install.
settings, such as the map view, and recent searches
the knocks and the notes that wait for a network connection

iOS deletes the other information of the app when the User deletes the app.

The Solar 360 app for Android keeps no cookies. It keeps the same information on the phone as the app for iPhone:

the session token, in a DataStore file. A key in the Android Keystore encrypts this file. The app removes the token at sign-out.
settings, such as the map view, and recent searches
the knocks and the notes that wait for a network connection

The backup of Android is off for the app, so no copy of this information goes to the Google backup or to another phone. Android deletes the information of the app when the User uninstalls the app. The app uses the network access of the phone to connect to the Service.

In the app for iPhone, iOS asks the User for permission before the app shows notifications. If the User allows them, Apple gives the app a device token for the Apple Push Notification service. The app sends the token to us. For each phone, we keep:

the device token, and a one-way hash of it
the User, and the session of the app that registered the phone
the version of the app, the id of the app build (the bundle id), and whether it is a development build
a random id that each notification carries. The phone uses it to hide the text of a notification for another User.
the time of the first registration, and the last time that the app registered the phone. The app does this each time that it opens.

We keep this information while the session of the app on the phone lives (see section 9). To stop the notifications, the User can turn them off in the settings of iOS. To remove the information of the phone, the User signs out in the app. We also delete it when the session ends or expires, and when the account is deleted. We delete it when Apple tells us that the token does not work, for example after the User deletes the app. It also goes when the Organization deactivates the User, or when another User registers the same phone.

In the app for Android, Android 13 and later ask the User for permission before the app shows notifications. If the User allows them, Google gives the app a registration token for Firebase Cloud Messaging. The app sends the token to us. We keep the same information for the phone, for the same time, and we delete it in the same cases. To stop the notifications, the User can turn them off in the settings of Android.

4. How we use information

We use Account Data, Billing Data, and Site data to:

create and run accounts, and let Users sign in
give the Service to Customers and their Users
send service emails, such as email verification, password reset, invitations, notifications, and billing notices
bill Customers and charge taxes through Stripe
keep the Service and its Users secure, and stop fraud and abuse
answer requests for support
answer a request from the contact form of the Site, and arrange a demo
stop bots and spam on the contact form of the Site
obey the law and enforce our terms of service
find and fix problems, with counts and error records that do not identify a person

We use Customer Data only to give, maintain, secure, and support the Service for the Customer, as the Customer instructs. For example, the Service sends booking confirmations, reminders, invitations to the project page, and notices of new messages and documents to homeowners for the Customer.

We do not:

sell personal information
share personal information for cross-context behavioral advertising
use personal information for ads of any kind
use Customer Data, Google user data, or Microsoft user data to train artificial intelligence (AI) models

If we send news about Solar 360 to a User, each such email has a link that stops these emails.

5. Cookies and browser storage

The Site uses no cookies and no tracking.

The Site keeps one value in the browser storage of your device (localStorage). The theme switch of the Site stores your choice there as s360-site-theme, with the value light or dark. This value is not a cookie. The Site does not send it to our servers or to anyone else. If you choose the theme of your device again, the Site removes the value. You can also remove it when you clear the browser data.

The contact form loads Cloudflare Turnstile (see section 3). Cloudflare says that Turnstile does not use cookies to collect or store information. Turnstile runs in a frame from challenges.cloudflare.com. It can keep a value in the browser storage of that frame. The Site cannot read this value.

The app in a web browser uses only the cookies that sign-in and security need:

a session cookie that keeps the User signed in. The session ends 7 days after the last use, or at sign-out.
short-term cookies during sign-in and during the two-factor check
a cookie that Cloudflare can set to protect the app from attacks

The app uses no cookies for analytics or ads. The browser storage of section 3 stays on the device until the app removes it or the User clears the browser data.

The Solar 360 app for iPhone uses no cookies. It keeps the session token in the Keychain of the phone (see section 3). The Solar 360 app for Android uses no cookies either. It keeps the session token in an encrypted file on the phone. The session of each app ends 30 days after the last day of use, or at sign-out. Each day of use starts the 30 days again.

We do not sell or share personal information. So a Global Privacy Control signal changes nothing. We still treat it as a valid request to opt out of sale and sharing.

6. Google and Microsoft data

A User can connect a Google account or a Microsoft account to sync the calendar with Solar 360. This is optional. The Service works without it.

Google Calendar

When a User connects Google Calendar, Solar 360 asks for these permissions (scopes):

openid and email: to know which Google account the User connected. We store its email address.
calendar.events.owned: to add, change, and remove the events of the appointments that the User books in Solar 360, in the calendars that the User owns. We use this permission only for the events that Solar 360 creates. We do not read, change, or delete other events.
calendar.freebusy: to read the busy times of the primary calendar for the next 14 days. Google gives only the start and the end of each busy time. We get no titles, places, descriptions, or guests.

How we use this data:

The Service uses the busy times to show free time slots and to prevent double bookings. Other Users of the Organization who book appointments see that the time is busy, with no details.
An event that Solar 360 writes contains the type of appointment, the name of the homeowner, the address of the property, and a link to the Solar 360 calendar.

How we keep and protect this data:

We store the access token and the refresh token encrypted with AES-256-GCM.
We keep the account email address, the tokens, and the copied busy times until the User disconnects the calendar, the Organization deactivates the User, or the account of the User is deleted.
When the User disconnects, we delete the tokens and the busy times, and we ask Google to revoke the access. The events that Solar 360 added stay in the Google calendar. The User can delete them there.
When the Organization deactivates the User, or the account of the User is deleted, we stop the sync at once. Then we delete the events that Solar 360 wrote to the calendar, ask Google to revoke the access, and delete the tokens and the busy times.

A User can disconnect at any time in Solar 360, or remove the access of Solar 360 in the Google Account settings.

Solar 360’s use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

We use Google user data only to give the calendar feature. We never use it for ads. We never sell it. We never use it to train AI models. We do not transfer it to others, except to give the calendar feature, to obey the law, or as part of a merger or a sale of our business. Our staff do not read Google user data, except with the agreement of the User, to investigate abuse or a security problem, or to obey the law.

Microsoft Outlook calendar

When the Service offers Microsoft Outlook calendar, a User can connect a Microsoft work, school, or personal account. Solar 360 then asks for these delegated permissions (scopes) of Microsoft Graph:

openid, email, and User.Read: to know which Microsoft account the User connected. We store its email address.
offline_access: to keep the connection active without a new sign-in each hour
Calendars.ReadWrite: to read the start and the end of the events of the next 14 days, so that we know the busy times. We ask Microsoft only for the start, the end, and the free or busy state of each event. We also use this permission to add, change, and remove the events of the appointments that the User books in Solar 360. We do not read, store, change, or delete the titles, places, descriptions, or guests of other events.

We use, keep, and protect this data as we do for Google Calendar, with one difference. Microsoft gives us no way to revoke the access. So when the User disconnects or the sync stops, we delete the tokens and the busy times, and the User can also remove the access of Solar 360 in the settings of the Microsoft account. The User can disconnect at any time in Solar 360.

Solar 360 uses data that it receives from Microsoft Graph only to give the calendar feature, and in compliance with the Microsoft APIs Terms of Use. We never use this data for ads. We never sell it. We never use it to train AI models. Our staff do not read it, except with the agreement of the User, to investigate abuse or a security problem, or to obey the law.

7. Maps

The map of the Service uses Google Maps Platform.

The map and the address search load from Google in the browser of the User. Google receives the IP address of the device, the area of the map, and the search text.
In the Solar 360 app for iPhone, the map loads through the Google Maps SDK for iOS. The SDK also sends Google the name and the version of the app, and an anonymous id that Google makes.
Our servers send the addresses and the map positions of properties to Google, to find their position on the map (geocoding) and to get Street View photos.
Google Solar API: when your organization uses Solar potential, we send the map position of a property to Google to get the solar data of its roof.
We do not send the names, phone numbers, or email addresses of homeowners to Google Maps.
We store only the Street View panorama id of a property. We do not store Street View images.

Google uses this information under the Google Privacy Policy. Use of the maps features is subject to the Google Maps End User Additional Terms of Service.

We share personal information only as this section states.

In the Organization. Users of an Organization see the Customer Data that their role allows. The Customer decides the role of each User.
With our service providers. We use the providers in Annex 2 of the Data Processing Addendum to host and run the Service: Amazon Web Services, Apple, Cloudflare, Stripe, Google, Microsoft, and Sentry. Apple delivers the notifications of the Solar 360 app for iPhone. Google delivers the notifications of the Solar 360 app for Android, through Firebase Cloud Messaging. Amazon Web Services also hosts the Site and sends the contact form to our team. Google also hosts our email: the support inbox, and the contact inbox that gets the contact form. Sentry receives the error reports and the performance data of section 3. Cloudflare also runs the bot check of the contact form (Cloudflare Turnstile). These providers process personal information only for us, under contracts that protect it. One exception: Cloudflare also uses the data of the bot check to improve its bot detection, as section 3 states.
With our parent company. Aeon Technologies Global, LLC gives engineering and operations staff to Solar 360. These people access personal information only to run, secure, and support the Service, and to answer requests from the contact form. They have a duty of confidentiality.
With services that a Customer or a User connects. Examples are Google Calendar and Microsoft Outlook calendar.
With homeowners. The Service sends emails to homeowners for the Customer, such as the invitation to the project page, booking confirmations and reminders, and notices of new messages and documents.
With push notification services. If a User turns on push notifications, they go through the push service of the maker of the browser, such as Apple, Google, Microsoft, or Mozilla. In a browser, the content is encrypted, so the push service cannot read it. In the Solar 360 app for iPhone, notifications go through the Apple Push Notification service. Apple gets the device token and the notification. The notification holds the title, the text, the number of unread notifications, the screen that it opens, and the random id of the phone. The connection to Apple is encrypted, but Apple can read the notification. In the Solar 360 app for Android, notifications go through Google Firebase Cloud Messaging. Google gets the device token and the notification. The notification holds the title, the text, the number of unread notifications, the screen that it opens, and the random id of the phone. It also holds the type of the notification and a tag. The phone uses the tag to replace an older copy of the same notification. The connection to Google is encrypted, but Google can read the notification. The text can hold a name, for example the name of a homeowner.
For legal reasons. We share information when the law or a valid legal process requires it. We also share it to protect the rights, property, or safety of Solar 360, our Customers, Users, or other people. When the law allows, we tell the Customer before we disclose its Customer Data.
In a sale of our business. If Solar 360 merges with another company, or sells all or part of its business, the information can go to the new owner. We tell Customers before this happens. The new owner must follow this policy for the information that it gets.

9. How long we keep information

Information	How long we keep it
Account Data	While the account exists. When a subscription ends, we delete it with the Customer Data of the Organization. When the only Owner deletes the Organization, the accounts of the other Users stay.
Sessions	In a web browser, 7 days after the last use. In the apps for iPhone and Android, 30 days after the last day of use. A session also ends at sign-out. We delete expired sessions within 30 days.
Phones that get notifications from the apps for iPhone and Android (the device token or the Firebase Cloud Messaging registration token)	While the session of the app on the phone lives. We delete the information of the phone within one day after the session ends or expires.
Failed sign-in records	15 minutes. We delete expired records within 30 days.
Server logs	30 days
Error reports and performance data	Up to 90 days in Sentry
Billing Data	As long as tax and accounting laws require
Customer Data	During the subscription, and 60 days after it ends. Then we delete it. When the only Owner deletes the Organization, we delete it at once, apart from the audit log.
Calendar tokens and busy times	Until the User disconnects the calendar, the Organization deactivates the User, or the account is deleted
Notifications in the app	180 days
Emails and push notifications in the send queue	30 days after we send them
Database backups	14 days
Old versions of files	30 days after a change or a deletion
Support emails	As long as we need them to help you and to keep a record of the help that we gave
Contact form emails	As long as we need them to answer your request, and for the business relationship that follows. We delete them when you ask.
Logs of the contact form	30 days. They hold no details of the form.
Data of the bot check of the contact form	We keep none. Cloudflare keeps the data that it receives as its own privacy policy states.

When a subscription ends, the Customer has 60 days to export its Customer Data. Then we delete the Customer Data and the Account Data of the Organization. The copies in backups go when the backups expire. We keep the Billing Data that the law requires. When the only Owner deletes the Organization, these 60 days do not apply, as section 11 states.

If you ask us to delete your Account Data, we delete it. We keep only the information that the law lets us or tells us to keep. You can also delete your account yourself in Profile, as section 11 describes.

10. Security

We protect personal information with technical and organizational measures. These include:

TLS encryption between the devices of Users and the Service
encryption at rest of the database, the backups, and the files
separation of each Organization with row-level security in the database
encryption of calendar tokens in the app
access for our staff only when their work needs it
files in a private store, reached only through signed links that expire after 15 minutes
database backups for 14 days, and server logs for 30 days

Annex 1 of the Data Processing Addendum lists the measures. No system is fully secure. If you find a security problem, tell us at support@solar360.io.

If a security breach affects your personal information, we tell you and the authorities as the law requires.

11. Your privacy rights

US State Privacy Laws give the residents of some states rights over their personal information. The rights depend on your state. They can include the right to:

know what personal information we have about you, and get a copy in a portable format
correct personal information that is not accurate
delete personal information
opt out of the sale or sharing of personal information, of targeted advertising, and of profiling. We do none of these things.
limit the use of sensitive personal information. We use sensitive personal information, such as the password of an account, only to give and secure the Service.
get equal service and prices when you use these rights
appeal our decision about your request

Delete your account

A User can delete the own account in Profile, on the web and in the Solar 360 apps for iPhone and Android. The app asks for the password. When the account has two-factor authentication, it also asks for a code of the authenticator app or a backup code.

The delete first ends each membership of the User in its Organization. Then it deletes the Account Data at once: the name, the email address, the password, the photo, the two-factor settings, and the sessions.
The delete also removes the phones of the User from push notifications. It stops a connected calendar, as section 6 states.
The delete removes the chat messages of the User and their files. The other Users see “Message deleted” in their place. The notifications, push notifications, and emails about these messages lose their text.
The knocks of the User stay with their property, with the outcome, the time, and the note. They lose the position of the phone and every link to the User.
The Organization keeps its other Customer Data, for example deals, leads, notes, and files. These records show “Former member” in place of the name. Send your questions about this data to the Organization.
The messages of a homeowner in the project portal stay with the Organization. They show “Former member” in place of the name.
If the delete of the Account Data fails, the account stays inactive, and the app tells the User. The User can try again. Our servers also try again by themselves, also when the User closes the app. If they cannot finish the delete, an alarm goes to our team. The delete is complete within 30 days.
When the delete is done, we send an email to the old address of the account.
The copies in backups and logs expire within 90 days, as section 9 states.

The only Owner of an Organization. The only Owner can delete the Organization together with the account, also when the Organization has other Users. Before the delete, the app and the web say it plainly: the Organization and all its data go. The other Users lose their access to it.

To confirm, the Owner types the name of the Organization and enters a code that we send to the email address of the account.
The delete removes every record and every file of the Organization at once. The Customer gets no time to export its Customer Data.
The record of the Organization stays, marked as closed. Its Billing Data, its access to towns, and its audit log stay with it. The audit log holds ids, and no email address of an invitation.
The billing ends at the end of the paid period. We collect only what the Customer owed before the delete. That is the invoices that are past due, and the charges of the last period for changed seats or add-ons, at its end. We make no refund for the use before the delete. If a payment comes for a subscription that started after the delete, we refund it.
The other Users keep their accounts and their sessions. They lose their membership, their open invitations, and their phones and browsers for the notifications of the Organization.
Each other User gets an email that the Organization is deleted.
The times of the list above apply to this delete too.

An Owner who is not the only Owner deletes only the own account. The Organization stays.

How to make a request

Send an email to support@solar360.io with the subject “Privacy request”.
Tell us your state, the right that you want to use, and the email address of your account, if you have one.
Answer our questions, so that we can confirm your identity. We use the information that we already have when we can.

An authorized agent can make a request for you. The agent must show your signed permission, and we can ask you to confirm your identity directly.

We answer within 45 days. If we need more time, we tell you why, and we can take 45 more days. A request is free of charge.

How to appeal

If we refuse your request, you can appeal. Reply to our answer, or send an email to support@solar360.io with the subject “Privacy appeal”. We answer an appeal within 45 days. If you do not agree with the result, you can contact the attorney general of your state.

Requests about Customer Data

If your information is in the Service because a solar company uses Solar 360, that company controls the information. For example, you are a homeowner or a lead of that company. Send your request to that company. If we get such a request, we tell you to contact the company. We also tell the company about the request when we can identify it. We help the company answer.

Information for California residents

In the last 12 months, we collected these categories of personal information as a controller:

Identifiers: name, email address, phone number, IP address, and account ids
Customer records: billing contact details, and the brand and the last four digits of a card
Commercial information: the plan, the seats, and the payment history
Internet activity: sessions, server logs, error reports, performance data, and the browser data of the bot check of the contact form
Professional information: the role and the team of a User, and the company name of a person who sends the contact form
Sensitive personal information: the email address and the password of an account

We collect this information from you, from the Customer that invites you, from your device, and from Stripe. We use it for the purposes of section 4. We disclose it to our service providers and to the Customer of your Organization, as section 8 states. We keep it as section 9 states.

In the last 12 months, we did not sell or share personal information. We do not sell or share the personal information of people under 16. We do not disclose personal information to others for their direct marketing.

12. Children

The Service and the Site are for businesses. They are not for people under 18. We do not knowingly collect personal information from people under 18. If we learn that we have Account Data of a person under 18, we delete it. If you think that this is the case, tell us at support@solar360.io.

13. Where we process information

The Service is for businesses in the United States. We store information in the United States, in the Amazon Web Services region us-east-1 (Northern Virginia). Some service providers, such as Cloudflare and Google, can process information in other countries.

14. Changes to this policy

We can change this policy. The date of the last change and the version number are at the top of this page.

For a material change, we send an email to the Owner of each Organization, and we show a notice in the Service. We do this at least 30 days before the change takes effect. The notice gives the date of effect.
Other changes, such as corrections and clearer words, take effect when we publish them on this page.
If a change lets us use personal information that we already have for a new purpose, we ask for consent when the law requires it.

15. Contact us

Solar 360, LLC, 31 Hawk Dr, Salem, NH 03079, United States
support@solar360.io