Compliance and risk statuses

A trip's status tells you where it sits in your approval flow. It says nothing about whether an A1 certificate has been issued or a posted-worker notification has been filed. That lives on three other fields, and this page covers all three.

The shape

trip
├─ riskAssessmentStatus          has the risk assessment finished?
└─ processRuns[]                 one per compliance obligation
   ├─ status                     is this obligation handled?
   ├─ process.key                which obligation — "a1-de", "pwd-fr", …
   └─ workflowRuns[]             the individual filings with the authority
      ├─ status                  how far along is this filing?
      ├─ workflow.type           SSN_REQUEST, NOTIFICATION_REPLY, …
      └─ files[]                 the resulting documents

processRuns and their nested workflowRuns come back on GET /trips/{id} — API Reference. They are not on the flattened /object response.

📘
Nothing runs before approval
premote only starts compliance processes for trips in APPROVED, APPROVED_MISSING_DATA, APPROVED_EDIT_PENDING or COMPLETED. On a PENDING or DRAFT trip, an empty processRuns array is expected, not a problem.

Run statuses

processRuns[].status and workflowRuns[].status share one set of values.

Status	Meaning	Terminal?
`IN_QUEUE`	Queued, not started	No
`IN_PROGRESS`	Running — typically an automated submission to an authority portal	No
`PREPARED`	The filing was generated but not sent — it needs a manual send, e.g. because no recipient address is on file	No
`SUBMITTED`	Filed with the authority; awaiting their reply	No
`SUCCESSFUL`	Completed. Where a document is expected, it is now attached	Yes
`COVERED`	No filing needed — the traveler already holds a long-term A1 covering this destination and these dates	Yes
`NOT_REQUIRED`	An exemption applies, so the obligation doesn't arise for this trip	Yes
`REJECTED`	The authority rejected the filing	Yes
`FAILED`	The run could not complete — a portal error, or data premote could not resolve	Yes
`DEADLINE_EXCEEDED`	The legal notification deadline had already passed when the trip was approved	Yes
`CANCELED`	Withdrawn, because the trip was cancelled	Yes
`OUTDATED`	Superseded by a later re-run of the same process. Ignore these — read the newest run per `process.key`	Yes

Three of these deserve a closer look.

`NOT_REQUIRED` is a good outcome

It means premote evaluated the obligation and concluded it doesn't apply — an existing work permit covers the traveler, a salary threshold isn't met, or the destination doesn't require a filing for this trip. Don't surface it as a gap.

`DEADLINE_EXCEEDED` means the filing window closed

Several countries require posted-worker notification a fixed period before travel starts. If a trip is approved after that window has already closed, premote records DEADLINE_EXCEEDED rather than filing late. This is a compliance exposure worth alerting on in your own system.

`OUTDATED` is bookkeeping

Re-running a process doesn't overwrite the old run — it marks it OUTDATED and creates a new one. Naively counting FAILED runs will therefore over-report, because superseded failures stay in the array. Group by process.key and take the most recent non-OUTDATED run.

Filter shortcuts on the trips list

GET /trips — API Reference — accepts two derived filters that roll the run statuses above into the question you actually want to ask. These values exist only as filter inputs — they are never returned as a status.

Social security (A1 and certificate-of-coverage processes):

Filter value	Selects
`REQUEST_PENDING`	Application filed, nothing back from the authority yet
`PRELIMINARY_ONLY`	Only a preliminary confirmation has arrived
`FINAL_AVAILABLE`	The final certificate has been issued
`FINAL_REJECTED`	The authority rejected the application

Posted-worker notifications:

Filter value	Selects
`SUCCESSFUL`	Notification filed and confirmed
`FAILED`	The notification could not be filed
`DEADLINE_EXCEEDED`	The notification window had already closed

Re-running a process

Action	Endpoint
Re-run after fixing data	`POST /processes/rerun/{tripId}` — API Reference
Re-file after the trip changed	`POST /processes/edit-run/{tripId}` — API Reference
Record a reply received outside premote	`POST /processes/process-run/{processRunId}/manual-reply` — API Reference
Move a run on manually	`POST /processes/workflow-run/{id}/status` — API Reference

🚧
Manual transitions are narrow, and failures are silent
POST /processes/workflow-run/{id}/status accepts only PREPARED → SUBMITTED and SUBMITTED → SUCCESSFUL / REJECTED. Anything else is ignored, and still returns a success response — so verify by re-reading the run rather than trusting the status code.

Risk assessment

Separate from compliance filings, and tracked on the trip itself.

Field	Values
`riskAssessmentStatus`	`PENDING`, `SUCCEEDED`, `FAILED`
`riskResult`	The assessment output, once `SUCCEEDED`

Assessments run asynchronously after the trip is created, so a freshly-created trip normally comes back PENDING. Poll riskAssessmentStatus until it leaves that state — don't read riskResult before it does.

A FAILED assessment can be retried with POST /trips/{id}/retry-assessment — API Reference. Previously-supplied answers are carried over, so a retry doesn't start from scratch.

Read the full result with GET /risk-rules/assessment/{tripId}/USERID — API Reference — or download the PDF report with GET /risk-rules/{tripId}/download-assessment — API Reference.

Risk levels

Value	Meaning
`LOW`	No concerns
`INFO`	Informational only
`MEDIUM`	Worth reviewing
`HIGH`	Significant risk
`ACTION_REQUIRED`	Something must be done before travel
`ATTENTION_REQUIRED`	Flagged for a human to look at
`NO_ACTION_REQUIRED`	Assessed, nothing to do

📘
A missing assessment isn't necessarily an error
Risk assessment is configured per company and per trip type, and can be switched off entirely or restricted so that only administrators may see the result. If you get no assessment where you expected one, check the company's configuration before treating it as a failure — and note that what your API user can see depends on its role.

Where the documents end up

Everything a successful run produces — A1 certificates, notification confirmations, authority replies — is attached to the trip as a file. Retrieving them is covered in Working with files.

The short version: a document only exists once its run reaches SUCCESSFUL, and every download URL premote returns is valid for five minutes.

Recap

Task	Endpoint
Read process and workflow runs	`GET /trips/{id}`
Filter trips by compliance outcome	`GET /trips`
Find out what data a parked process needs	`GET /processes/{tripId}/missing-data`
Re-run processes after fixing data	`POST /processes/rerun/{tripId}`
Re-file after a trip change	`POST /processes/edit-run/{tripId}`
Move a workflow run on manually	`POST /processes/workflow-run/{id}/status`
Retry a failed risk assessment	`POST /trips/{id}/retry-assessment`
Read the risk assessment	`GET /risk-rules/assessment/{tripId}/USERID`
Download the risk report	`GET /risk-rules/{tripId}/download-assessment`

The shape

Nothing runs before approval

Run statuses

NOT_REQUIRED is a good outcome

DEADLINE_EXCEEDED means the filing window closed

OUTDATED is bookkeeping

Filter shortcuts on the trips list

Re-running a process

Manual transitions are narrow, and failures are silent

Risk assessment

Risk levels

A missing assessment isn't necessarily an error

Where the documents end up

Recap

`NOT_REQUIRED` is a good outcome

`DEADLINE_EXCEEDED` means the filing window closed

`OUTDATED` is bookkeeping