> For the complete documentation index, see [llms.txt](https://api-docs.visadoc.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://api-docs.visadoc.co/use-cases/background-operational-sync.md).

# Background Operational Sync

**One line:** Keep your own ops dashboard in sync with the case of record: read-only, no PII stored on your side beyond what you already hold.

**Best for:** Compliance dashboards, ops queues, and case-closure automation.

## Flow

```mermaid
sequenceDiagram
  participant You
  participant VisaDoc
  Note over You,VisaDoc: First run: load current cases
  You->>VisaDoc: POST /applications/search (your scope, paged)
  VisaDoc-->>You: cases + statuses
  loop every scheduled run
    You->>VisaDoc: POST /actions/search (created_at since last run)
    VisaDoc-->>You: events since last run
    You->>VisaDoc: POST /applications/search (ids of changed cases)
    VisaDoc-->>You: current state
  end
  You->>You: Close the loop on Decision Made
```

1. **First run:** page through `POST /applications/search`, filtered to your scope (for example by `company_id`, `status`, or a list of your `assessment` IDs).
2. **Every run:** `POST /actions/search` with `{ "filters": { "created_at": { "gt": <last run, epoch ms> } } }`. Each event has `type`, `old_value`, `new_value`, `user_id`, `application_id` and `created_at`. Page until you get fewer items than `per_page`.
3. Re-fetch the cases those events touched: `POST /applications/search` with `{ "filters": { "id": ["…", "…"] } }`, or `GET /applications/{application_id}` one by one. Add `POST /documents/search` by `application_id` if you track documents.
4. Store the newest `created_at` you received as the starting point for the next run, rather than your own clock.
5. When a case reaches `Decision Made`, [read the outcome](/statuses.md#reading-the-outcome) before you close it in your system.

{% hint style="info" %}
Don't sync incrementally on the applications' own `created_at`: it only catches new cases, not changes to existing ones. The audit trail (`POST /actions/search`) is what records changes.
{% endhint %}

**Consider:** Status is poll-based. Visa cases move over hours and days, so frequent polling gains little. Use the audit history to trigger your closure and amend handling, and check [Trip changes and erasure](/trip-changes-and-erasure.md) for what's still possible at each status.

**Endpoints:** `POST /applications/search`, `POST /actions/search`, `GET /applications/{application_id}`, `POST /documents/search`.