Design Requests

Aurora offers a Site Modeling Service, through which you can order 3D Models from Aurora’s Site Modeling Service and EagleView Powered Models. Expert Models provide fast, accurate 3D models of a property created by our team of expert designers. EagleView Powered Models provide an additional level of accuracy, and are ideal for sold projects or projects that require the highest level of accuracy from the start.

Aurora’s Site Modeling Service

Aurora’s 3D Modeling Service allows users to request 3D models within the Aurora application. 3D models can also be requested via the API. The 3D Modeling Service is a paid service. You must have sufficient credits available to make a 3D Modeling Request (aka a design request). You can only request designs for residential projects.

Once you make a design request, a team of professional CAD designers will create an accurate 3D model of your work site (including buildings and trees). The requests are fulfilled during business hours. Our team aims to complete them within 3 hours. As an organization, you then have the choice between manually reviewing the designed 3D model in the Aurora application, or programmatically accepting it without a review via the API. The choice allows you to strike an appropriate balance of speed vs. quality given your specific business constraints. For example, you can accept 90% of all design requests in CA via the API and leave the 10% for a manual review, while manually reviewing all design requests in other states. Please note: once you have accepted a completed 3D model, a design containing the model of the site will automatically be created in the project.

Each design request has a status. There are 3 possible flows of a design request through the state machine.

1. A design request object is created and is rejected by the CAD designers. No 3D model is generated. The state transition for that design request object is: submitted => designer_rejected.
   This can occur due to:

• missing or unclear imagery for the project location.

• an ambiguous project location where the designer is unclear which building needs to be modeled, e.g. the project marker falls on a street or between two large homes.

• the building displayed is a commercial roof top, which is currently not supported.

2. A design request object is created and afterwards successfully fulfilled by our professional designers. You accept the design request and it is then converted into an actual design object within the Project. You can accept the design request manually through the Aurora application or programmatically via the API. The state transition for that design request object is: submitted => designer_completed => accepted.

3. A design request object is created and afterwards successfully fulfilled by our professional designers. You manually review the design request through the Aurora application. The quality of the generated 3D model does not meet your expectations and you reject the request. A rejection always requires feedback because it allows us to improve the quality of the service. The rejection is not possible via the API. The state transition for that design request object is: submitted => designer_completed => rejected.

📘

Please note that only one design request can be in progress (in either status submitted or designer_completed) for a given Project at any given time.

Testing your Integration

To facilitate testing your integration, there are several addresses with special behavior that mock the process without using credits or requiring manual intervention.

If you submit a design request for one of the following addresses (including submitting a lat/long coordinate that falls on the roof of one of the addresses), the API will mimic the process of manual fulfillment instantly. This includes populating the design, updating the status to designer_completed, and making a webhook call if webhooks are configured for the design_request_completed event.

If you submit a design request for the following address (including submitting a lat/long coordinate that falls on the roof of the address), the API will mimic the process of manual rejection. This includes setting the status to designer_rejected, setting a rejection reason, and making a webhook call if configured for the design_request_rejected event.

Related Tutorials:

• Request a roof model built
• Create a 3D roof model for testing

EagleView Design Requests

You can request an EagleView Powered Model in the Aurora app or via the API by creating an EagleView design request. Note that you can only request one EagleView Powered Model per project and it has to be for a residential project in the United States.

Once you place an EagleView design request, the EagleView team of professional designers will create an accurate 3D model of your site. The model will include the primary building and a detached garage, if present. The model will not include trees. You won’t be able to retrieve Roof Summary for models created by EagleView.

There is a three-business-hour turnaround time for EagleView design requests. For more information on their business hours, see here.

You can manually review the designed EagleView Powered Model in the Aurora application, or programmatically accept it without a review via the API. Once you have accepted a completed EagleView Powered Model, a design titled “EagleView Powered Model” containing the model of the site will automatically be created in the project.

Each EagleView design request has a design_status. There are 3 possible flows of an EagleView design request.

1. An EagleView design request is created and is rejected by the EagleView designers. No EagleView Powered Model is generated. The state transition for that EagleView design request object is: requested => design_failed.
   This can occur due to:

• missing or unclear imagery for the project location.

• an ambiguous project location where the designer is unclear which building needs to be modeled, e.g. the project marker falls on a street or between two large homes.

• the building displayed is a commercial roof top, which is currently not supported.

2. An EagleView design request object is created and afterwards successfully fulfilled by the EagleView designers. You accept the EagleView design request manually through the Aurora application or via the API, and it is then converted into an actual design object within the project. The state transition for that EagleView design request object is: requested => completed => accepted.

3. An EagleView design request object is created and afterwards successfully fulfilled by the EagleView designers. You manually review the EagleView design request through the Aurora application. The EagleView Powered Model does not meet your expectations and you reject the request. A rejection always requires feedback because it allows us to improve the quality of the service. The rejection is not possible via the API. The state transition for that EagleView design request object is: requested => completed => in_dispute.

Testing your Integration

To facilitate testing your integration, there are several addresses with special behavior that mock the EagleView design process without incurring costs or requiring manual intervention.

If you submit an EagleView design request for one of the following addresses (including submitting lat/long coordinates that falls on the roof of one of the addresses), the API will mimic the process of manual fulfillment instantly. This includes updating the design_status to completed and making a webhook call if webhooks are configured for the eagleview_design_request_status_changed event. If auto_accept is true, it will also include populating the design and updating the design_status to accepted.

If you submit an EagleView design request for the following address (including submitting a lat/long coordinate that falls on the roof of the address), the API will mimic the process of manual rejection. This includes setting the design_status to design_failed and making a webhook call if webhooks are configured for the eagleview_design_request_status_changed event.