Workflow guide

VehiclePhoto for group admins

A shared production system needs precise boundaries: which stores exist, who can enter each one, what brand rules are enforced, who can spend, which partners hold keys, and where sensitive changes are recorded. VehiclePhoto exposes those responsibilities as named administrative surfaces instead of hiding them inside the image editor.

Real product surfaces

Today's pressure

  • Stores and team membership must reflect the current organization.
  • Roles should grant enough access without exposing unrelated controls.
  • Brand and privacy rules need consistent enforcement across locations.
  • Billing, credits, integrations, and keys require accountable ownership.
  • Privileged changes need a reviewable history for investigation and support.

What changes

Stores

Add and manage the stores in the group, then use the active-store context for production work. Store records define the operational boundary used by capture, library views, settings, and location-level access.

Team

Invite teammates, assign roles, and move people between stores. Permission checks cover capture, editing, approval, brand, privacy, billing, and administrative actions, allowing responsibilities to remain separate without shared credentials.

Brand governance

Choose whether the group enforces a shared brand kit or house look and whether local adjustment is allowed. The policy is stored centrally so a location cannot unknowingly drift merely because a visual instruction was passed informally.

Billing & usage

Review the plan, billing cadence, credit balance, and usage, then make permitted tier changes. Credit grants, rollover, one-off purchases, and spending use a common ledger that supports clearer reconciliation across the group.

API keys

Create scoped partner keys for REST API v1 and webhook work. Each key carries named permissions, making it possible to grant ingest, processing, read, or webhook access without sharing an interactive account session.

Activity

Inspect privileged changes after setup and during support. The running activity record provides the place to trace administrative actions when a role, store, policy, billing decision, or integration credential needs review.

First hour

  1. 01

    Map stores

    Open Stores and compare the list with the real operating structure. Add only confirmed locations, then switch active context to ensure production and capture surfaces read the intended store boundary.

  2. 02

    Assign access

    Open Team and give test users the narrow roles matching capture, editing, approval, brand, and billing duties. Exercise one permitted and one refused action so the setup is proven rather than inferred from labels.

  3. 03

    Set shared rules

    Review Brand governance and privacy configuration, decide what is enforced, and apply the chosen policy to sample work from two stores. Confirm local flexibility behaves exactly as intended before wider rollout.

  4. 04

    Audit connections

    Inspect Billing & usage, issue one least-privilege API key, register a test webhook if needed, and open Activity afterward. Record the owner and rotation plan for each credential before any partner uses production data.

Connected responsibilities

The same listing crosses capture, review, brand, delivery, and account controls. Continue with the adjacent workflows that share those handoffs.

Pricing

Plans start at $49 per month with group billing and credit visibility available through the administrative console. A $39 Listing Pass supports one-off work, and the free trial grants five watermarked credits. Estimate capacity from combined store volume and premium output use.

FAQ

Questions answered

Can access vary by duty?

Yes. Roles and permissions separate capture, asset editing, approval, brand, privacy, billing, and administration. Test each assigned role with a real route before launch, especially approval, billing, governance, and key creation, because those actions change shared state.

Can policy span stores?

Brand governance can enforce a group kit or house look while controlling whether local changes are allowed. Store and group context are explicit in the account. Use two representative stores during setup to verify inherited and local behavior.

How are partners connected?

Scoped API keys authenticate REST API v1, and webhook endpoints provide signed event delivery. Direct DMS push and syndication connectors are not live. Keep key scope, owner, destination, secret rotation, and revocation steps documented for each partner connection.

Try the real workflow.

See it on your own photos.