.png)
For a single dealership, vehicle photography can look like a creative problem. For a dealer group managing hundreds or thousands of vehicles across multiple rooftops, it quickly becomes an infrastructure problem.
Every location needs to capture inventory quickly, produce reasonably consistent results, associate media with the correct VIN and stock number, publish it to the right VDP, and handle vehicles entering and leaving inventory every day.
Historically, improving that process often meant buying more hardware or building specialized software internally. Dealer groups could invest in turntables, dedicated photo booths, controlled studios, or custom computer-vision systems. A sophisticated physical photography installation can easily become a five-figure project, with some studio configurations reaching $40,000 or more once equipment, construction, cameras, lighting, and integration work are considered.
The alternative is increasingly API-driven.
A modern automotive 360 API can move much of the complexity from individual dealership locations into a centralized software workflow. Staff capture a handheld vehicle walk-around, the API processes it, and the resulting frames, sprite sheets, metadata, annotations, geometry, and hosted experiences can flow directly into existing automotive systems.
That changes the build-versus-buy discussion considerably.
Large dealer groups and automotive software companies often have engineering teams capable of building sophisticated imaging systems.
The more important question is whether building and maintaining the entire computer-vision pipeline is where those engineering resources create the most value.
A complete 360° vehicle imaging system can involve:
Building a prototype for one vehicle is one problem.
Keeping that pipeline working reliably for tens of thousands of vehicles captured by different employees, phones, dealerships, weather conditions, backgrounds, and walking speeds is something else entirely.
That is where an API starts to become attractive.
The CloudPano Spin API overview describes a workflow in which developers POST a handheld walk-around video and receive a processed 360° spin with hosted frames and sprite sheets. Processing is asynchronous, allowing the imaging process to become part of a larger inventory workflow rather than a manual editing task.
An API does not necessarily replace the person capturing the vehicle.
It replaces much of the specialized infrastructure that traditionally sits around that person.
A dealer may create a dedicated photography area with:
This can produce excellent results, especially at a high-volume centralized facility.
The challenge appears when a dealer group has 10, 20, or 50 rooftops.
Now the company must decide whether to reproduce that physical environment at every store, move vehicles through a centralized imaging center, or accept different photography standards between locations.
With an automotive 360 API, the capture device can be something employees already understand: a smartphone.
The operator walks around the vehicle once.
Software handles more of what happens next.
CloudPano's current capture guidance recommends one complete landscape-orientation circle around the vehicle, generally lasting about 20–60 seconds. The API accepts MP4, MOV, and WebM files up to 500 MB.
That does not eliminate the need for good capture habits.
It does dramatically reduce the amount of specialized hardware required at each dealership.
One argument for buying API infrastructure instead of building the underlying imaging stack is implementation surface area.
The core Spin API workflow uses three primary endpoints:
POST /api/v1/spins
GET /api/v1/spins/:id
GET /api/v1/spins
The first submits a vehicle for processing.
The second retrieves an individual job and its current status.
The third returns the latest spin jobs for the account.
A basic upload can look like this:
curl -X POST https://app.cloudpano.com/api/v1/spins \
-H "Authorization: Bearer sk_spin_YOUR_KEY" \
-F "video=@walkaround.mp4" \
-F "stock_number=A4821" \
-F "vin=1FTFW1E50MFA00000"
The API returns a job ID rather than keeping the connection open until all processing is complete.
Your application then polls:
curl https://app.cloudpano.com/api/v1/spins/rJx0aB1c \
-H "Authorization: Bearer sk_spin_YOUR_KEY"
The documented integration pattern is to check approximately every 10 seconds while the job remains queued or processing. A successful job eventually becomes ready; an unusable capture can become failed. GET /api/v1/spins currently returns the latest 25 jobs.
This matters operationally because polling, retries, exception handling, and publishing can all be incorporated into an existing inventory automation system.
There is no need to design production architecture around undocumented webhooks or SDKs.
The difficulty with decentralized vehicle photography is rarely just image resolution.
It is consistency.
Employee A may walk slowly around the driver's side.
Employee B may stand farther away.
Employee C may capture a vehicle in front of a busy service lane.
Employee D may walk past the original starting position.
An API-based workflow can normalize some of those differences.
centering=true keeps the vehicle at a more consistent scale and position throughout the resulting spin.
The API uses mirrored, blurred edge extensions where geometric adjustments expose areas outside the original frame, avoiding distracting moving black borders.
For a dealer group, this is less about making one image impressive and more about making thousands of listings feel like they belong to the same merchandising system.
car_blur=true applies a studio-style blur around the vehicle while retaining a sharper area near the tires.
That can reduce distracting differences between rooftops: parked vehicles, buildings, signs, employees, service bays, fencing, and lot traffic.
Instead of demanding that every dealership create the same physical background, software can create more consistent presentation after capture.
smooth_rotation=true addresses something that is difficult to standardize through employee training alone: walking speed.
Video cameras record at consistent time intervals.
People do not walk at consistent angular intervals.
If someone slows near the front grille and speeds up along the passenger side, selecting frames purely by video time can make the resulting spin feel uneven.
The Spin API uses recovered camera movement to select frames at more consistent angular steps and can remove excess overlap beyond the completed revolution.
The default output is currently 96 frames, with a documented range from 12 to 120.
Using an API does not mean giving up control.
It can mean choosing which parts of the stack are worth owning.
A dealer website provider may not gain a strategic advantage by building its own structure-from-motion pipeline.
It may gain a major advantage by building the best vehicle shopping interface around the output.
That company can spend engineering resources on:
The underlying spin processing becomes infrastructure.
The customer-facing experience remains proprietary.
That is often a much cleaner build-versus-buy boundary.
Processing the spin is only half of the system.
It also needs to load quickly on the VDP.
result.frames provides individually hosted JPEGs in rotation order.
result.mosaics packages frames into sprite sheets designed for faster web playback. The current response includes a low-resolution mosaic plus higher-resolution sheets, allowing a browser-based viewer to become interactive without requesting every frame as a separate asset first.
A practical architecture can use both.
Use sprite sheets for fast rotation.
Use individual high-resolution frames when the shopper stops and zooms.
This separates the performance requirements of playback from the image-quality requirements of detailed inspection.
For a deeper look at that delivery architecture, see How the Spin API Delivers 360 Spins With Sprite Sheets and Frame Arrays.
One of the biggest differences between a simple image-extraction service and a more advanced automotive 360 API is what can be built on top of the reconstructed vehicle.
The Spin API can provide:
carPoseUrl for per-frame camera posescarCloudUrl for a sparse vehicle point cloudcarMeshUrl for a low-poly vehicle hullThese outputs live in what the documentation calls Reconstruction Space.
There are several important limitations developers should understand.
The coordinates use arbitrary units rather than guaranteed real-world meters. The origin and orientation are also arbitrary rather than being guaranteed to align with gravity or the centerline of the vehicle.
Most importantly, reconstruction space belongs to that specific processed spin.
If the spin is reprocessed, the 3D reconstruction can change. Anchors from an earlier processing result should therefore not be compared directly against the newly generated geometry. Applications should fetch the updated result and use the newly projected annotation positions.
That may sound technical, but the business implications are interesting.
It allows products to move beyond "drag the car left and right."
A recon platform could place condition notes on sheet metal.
A wholesale marketplace could highlight dents or wheel damage.
An inspection application could use the reconstructed mesh to determine whether an annotation should be visible from the shopper's current angle.
The computer-vision layer becomes reusable infrastructure for additional automotive products.
At dealer-group scale, media should never become disconnected from inventory.
The Spin API accepts vin and stock_number as optional multipart fields and echoes them back in the result metadata. VIN is also stored on the hosted tour.
That enables a workflow such as:
Vehicle acquired → Stock created → Walk-around captured → Spin processed → VIN matched → VDP updated
No employee should need to download 96 images, rename them, upload them to another platform, and manually find the correct vehicle.
That kind of workflow becomes especially valuable for:
The build-versus-buy decision becomes even clearer when existing inventory is involved.
Imagine deploying 360° merchandising across 5,000 active listings.
An internally built computer-vision system needs production infrastructure before the first large backfill even begins.
An API integration can instead treat every existing vehicle as a processing job.
Queue the available footage.
Submit each vehicle with its VIN and stock number.
Poll for completion.
Route failures into a recapture queue.
Publish successful results automatically.
Once the architecture works for 100 vehicles, the same general workflow can process 1,000 or 10,000 without asking every rooftop to adopt new physical studio hardware.
APIs are not automatically the correct answer for every organization.
A company may still choose to build its own processing stack when computer vision itself is a strategic product, when it needs models or reconstruction techniques unavailable from external providers, or when its scale justifies owning specialized infrastructure.
The distinction is important.
Do not compare "API cost" against "zero cost to build ourselves."
In-house systems have costs too:
The relevant question is total ownership cost and strategic value.
If your competitive advantage is selling cars, powering dealer websites, managing inventory, or operating a marketplace, owning every layer of video reconstruction may not be necessary.
A scalable automotive 360 API lets dealer groups separate physical capture from computational processing.
Employees capture vehicles where the vehicles already are.
The API standardizes the resulting media.
Inventory identifiers connect those assets to the correct records.
Developers decide how the finished experience should appear across VDPs, native applications, marketplaces, and DMS-connected products.
That architecture can be easier to scale than reproducing a specialized imaging studio at every rooftop—and considerably faster than developing and maintaining every component of a computer-vision pipeline internally.
Dealer groups are not moving toward APIs because custom technology is impossible to build.
They are doing it because infrastructure decisions should reflect where engineering time creates the most value.
If a proven processing layer can transform handheld footage into centered frames, smooth rotations, sprite sheets, high-resolution images, annotations, geometry, and hosted experiences, your team can spend more time building the inventory and shopper workflows around those assets.
That is the larger opportunity behind the automotive 360 API model.
Capture can remain distributed.
Processing becomes centralized.
Inventory mapping becomes automated.
Delivery becomes programmable.
And the dealership does not have to install the same expensive photography system at every location.
The CloudPano Spin API is currently free during the preview period, and accounts support up to 10 active API keys.
Read the full Spin API docs → app.cloudpano.com/developers/spin-api
Create a free preview API key, submit a real dealership walk-around, and evaluate the output against the time and engineering effort required to build the same processing infrastructure internally.
Compact, ready to go anywhere
Interchangeable lens that’s upgradeable
Dual 1-inch sensors for improved clarity and low light performance
Dynamic range and 6K 360° capture
360° photo resolution at 21MP
8K 360° video recording for ultra-detailed visuals.
4K single-lens mode for traditional wide-angle shots.
Invisible selfie stick effect for drone-like perspectives.
2.5-inch touchscreen with Gorilla Glass protection.
Waterproof up to 33ft for underwater shooting.
360° photo resolution in 23MP
Slim design at 24 mm thick
Built-in image stabilization for smooth video capture.
Internal 19GB storage for photo and video storage.
Wireless connectivity for remote control and sharing.
60MP 360° still images for high-resolution photography.
5.7K 360° video recording at 30fps.
2.25-inch touchscreen for intuitive control.
USB Type-C port for fast charging and data transfer.
MicroSD card slot for expandable storage.
.png)
.png)
Try it free. No credit card required. Instant set-up.
.svg){kind=small}
.svg){kind=small}