Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/juanmatz/inspection-form-euroautos/llms.txt

Use this file to discover all available pages before exploring further.

All inspection data — including checklist responses, photos, and customer signatures — is stored locally in the browser using IndexedDB, allowing the Euroautos Inspection Form to function fully without an internet connection. When a backend is configured, data is synchronised automatically once connectivity is restored, ensuring no work is lost regardless of network conditions.

​
Storage Architecture

The app uses a two-layer storage model:
  1. IndexedDB (primary) — All inspection data is written to IndexedDB immediately as the inspector works. This is the source of truth for the local session and is what the app reads from when rendering inspection lists, section views, and reports.
  2. Backend REST API (optional) — When the environment variable VITE_API_URL is set at build time, the app registers mutations in a local sync_queue store and flushes them to the backend whenever the browser reports an online connection. This enables cross-device access and centralised record-keeping without blocking the inspector’s workflow.
The diagram below summarises the flow: 
Inspector → IndexedDB (instant, always available)
                 ↓  (when online + VITE_API_URL set)
            sync_queue → POST /api/v1/inspections → Backend database

​
IndexedDB Stores

The app opens a single IndexedDB database named euroautos at version 1. It contains three object stores:
StoreKeyDescription
inspectionsid (UUID)Full inspection JSON objects, including all sections, checklist items, status, and metadata.
photosid (UUID)Base64-encoded JPEG photo data linked to individual inspection checklist items via itemId and inspectionId foreign keys.
sync_queueid (UUID)Pending mutations (creates and updates) awaiting backend synchronisation. Each entry records the target inspectionId, the mutation type, and the serialised payload.
Each photo entry in the photos store contains the fields id, inspectionId, itemId, mimeType, data (Base64 string), and createdAt. This normalised structure keeps the inspections store lean — item photo arrays store only photo id references, not the raw data.

​
Reading Stored Inspections

You can read stored inspections directly from IndexedDB using the idb library (already bundled with the app) or the raw IndexedDB API. The following snippet uses the idb helper: 
import { openDB } from 'idb';

const db = await openDB('euroautos', 1);
const all = await db.getAll('inspections');
console.log(`${all.length} inspections stored locally`);
To read a single inspection by its UUID: 
const inspection = await db.get('inspections', 'insp-7f3a2b1c-4d5e-6f7a-8b9c-0d1e2f3a4b5c');
console.log(inspection.status); // e.g. "completed"
To read all photos belonging to a specific inspection, use the inspectionId index: 
const tx = db.transaction('photos', 'readonly');
const index = tx.store.index('inspectionId');
const photos = await index.getAll('insp-7f3a2b1c-4d5e-6f7a-8b9c-0d1e2f3a4b5c');
console.log(`${photos.length} photos found`);

​
Storage Limits

Browser IndexedDB storage is drawn from the same quota as other origin storage (Cache API, localStorage, etc.). Browsers typically allocate between 50% and 80% of available free disk space to a single origin, but the exact limit varies by browser and platform:
BrowserQuota model
Chrome / EdgeUp to ~80% of available disk space per origin
FirefoxUp to 50% of available disk space, capped at 2 GB without persistent storage permission
SafariDynamic quota; may be as low as 1 GB without persistent storage grant
Mobile browsersGenerally lower limits; Safari on iOS enforces stricter caps
Photos are by far the largest consumers of local storage. A single high-resolution JPEG can exceed 3–5 MB after Base64 encoding. A typical full inspection with 20 photos can consume 60–100 MB. On devices with limited free disk space, inspectors should export and clear completed inspections regularly.
To avoid running into quota limits in production, consider the following practices:
  • Enable backend sync (VITE_API_URL) so that synced inspections can be cleared from local storage without data loss.
  • Lower the maximum photo size using the VITE_MAX_PHOTO_SIZE_MB environment variable (default: 5).
  • Encourage inspectors to export and clear completed inspections at the end of each shift.

​
Exporting Local Data

The app provides an “Exportar datos” option in the Settings screen (⚙ icon → Almacenamiento → Exportar datos). Tapping this button:
  1. Reads all records from the inspections store.
  2. Reads all associated photos from the photos store and embeds them inline.
  3. Serialises the result as a single JSON file.
  4. Triggers a browser file download named euroautos-export-<ISO-date>.json.
The exported file is human-readable and can be re-imported into any Euroautos instance or processed by external tooling. The schema of the export file matches the Inspection JSON Schema documented separately.

​
Backend Sync

When VITE_API_URL is set at build time (e.g. VITE_API_URL=https://api.euroautos.example.com), the app activates its sync pipeline:
  1. Every time an inspection is created or updated, a corresponding entry is written to the sync_queue store alongside the IndexedDB write.
  2. The app listens for the browser’s online event. When fired, it dequeues all pending entries from sync_queue and POSTs them to {VITE_API_URL}/api/v1/inspections.
  3. On a successful 2xx response, the sync queue entry is deleted. On failure, it is retried with exponential back-off on the next online event.
Idempotency is handled using the inspection id (a UUID generated client-side) as the idempotency key. The backend is expected to treat a POST with a known id as an upsert, making it safe to replay queue entries after a partial failure: 
POST /api/v1/inspections
Content-Type: application/json
Idempotency-Key: insp-7f3a2b1c-4d5e-6f7a-8b9c-0d1e2f3a4b5c

{
  "id": "insp-7f3a2b1c-4d5e-6f7a-8b9c-0d1e2f3a4b5c",
  "status": "completed",
  ...
}
The sync pipeline only processes outbound mutations (device → backend). There is currently no inbound sync (backend → device). Inspections created on other devices are not pulled down automatically; this feature is on the roadmap.

​
Clearing Data

The app provides a “Limpiar datos” option in the Settings screen (Almacenamiento → Eliminar todo). This permanently deletes all records from the inspections, photos, and sync_queue stores.
Clearing browser storage is irreversible. Any inspections that have not yet been synced to the backend or exported as a JSON file will be permanently lost. Always use “Exportar datos” before clearing local storage. If backend sync is enabled, verify the sync queue is empty (green indicator on the Settings screen) before proceeding.
You can also clear storage manually via browser developer tools:
1

Open DevTools

Press F12 (or Cmd+Option+I on macOS) to open the browser DevTools.
2

Navigate to Application storage

Click the Application tab, then expand IndexedDB in the left sidebar.
3

Select the euroautos database

Click euroautos → right-click each object store and choose Clear.
4

Reload the app

Reload the page. The app will reinitialise the database with empty stores.

Build docs developers (and LLMs) love

Get started for freeTalk to us