Trip statuses

Every trip carries a status. It is returned by GET /trips/{id} — API Reference — and GET /trips/{id}/object — API Reference — and it is the field to key your integration off.

This page is the complete reference: what each value means, how a trip arrives there, and what you can do about it.

At a glance

Two further values, INCOMPLETE and ASSIGNED, are legacy — see Legacy values below.

The statuses in detail

DRAFT

A trip the traveler has started but not submitted. It is a real row with a real id, so you can read and update it, but premote treats it as provisional: drafts are excluded from policy quota counting and duplicate detection, and they trigger no approvals, no risk assessment and no compliance processes.

Drafts are the only trips that can be hard-deleted (DELETE /trips/{id} — API Reference) and the only trips where edits apply immediately instead of going through a change request.

Submitting a draft (POST /trips/{id}/update-draft with upgrade: true — API Reference) upgrades the same row in place — the id does not change — and moves it to PENDING, or straight to APPROVED if the matching policy auto-approves.

PENDING

Submitted and awaiting approval. This is the default landing state for a new trip.

For multi-step approval chains, the trip stays PENDING as each approver signs off, and only flips to APPROVED once the final one does. To show progress, read approvals on the full trip (GET /trips/{id}) and compare its length against the approval rules on policy.approvalRules.

APPROVED

Fully approved. Either every approval rule was satisfied, or the matching policy auto-approves, or the trip arrived from an integration configured to auto-approve.

This is the state that matters most for compliance: reaching it is what triggers premote to start filing A1 applications, posted-worker notifications, and the rest.

APPROVED_MISSING_DATA

The one status that needs you to do something.

The trip is approved, but a compliance process — or an administrator's explicit request — needs field values that aren't filled in yet. premote parks the trip here rather than filing an incomplete application with an authority. The workflow does not start until the data arrives.

To resolve it:

1. Ask what's missing — GET /processes/{tripId}/missing-data — API Reference.
2. Fill traveler profile fields with POST /users/{id}/data — API Reference — and trip fields with POST /trips/{id}/data — API Reference.
3. premote re-checks automatically and returns the trip to APPROVED once everything required is present. You do not call a status endpoint to leave this state — and you can't.

Note that missing data can be on the traveler's profile rather than the trip itself, so filling only trip fields may not clear it. The missing-data response tells you which is which.

APPROVED_EDIT_PENDING

An already-approved trip has an open change request. The trip's previous status is retained internally and restored once the request is decided.

Approved trips can't simply be edited — changes go through POST /trips/{id}/request-change — API Reference — and are then accepted or rejected with POST /trips/{tripId}/change/{requestId} — API Reference. Either outcome returns the trip to APPROVED; accepting also applies the new values.

Change requests are automatically rejected if the trip is cancelled or declined while one is open.

CANCEL_REQUESTED

Someone asked to cancel a trip that requires an administrator to sign the cancellation off. Whether cancellation needs approval is a policy setting, so the same call can produce CANCELED for one company and CANCEL_REQUESTED for another — handle both.

From here the trip either becomes CANCELED, or is restored to its previous status via POST /trips/{id}/restore-status — API Reference.

CANCELED

Terminal. premote records who cancelled it, when, and why, rejects any open change request, and — importantly — kicks off cancellation runs for compliance filings that were already submitted, so a withdrawn notification is properly retracted with the authority.

So: the trip is finished, but its processRuns may still be doing work. Don't tear down tracking the instant you see CANCELED if you care about the cancellation filings.

DECLINED

An approver rejected the trip. Terminal — a declined trip cannot be re-approved. Any open change request is rejected. Create a new trip if the traveler still needs to go.

COMPLETED

Set manually by an administrator after travel has happened, as a bookkeeping step. Only reachable from APPROVED. premote does not set it automatically when the end date passes, so don't rely on it to mean "the trip has ended" — compare endDate against today for that.

Transitions

Only these moves are legal. Anything else is rejected.

Driving a transition

POST /trips/{id}/status — API Reference

curl -X POST https://api.premote.io/v1/trips/456/status \
  -H 'Authorization: Bearer <token>' \
  -H 'Content-Type: application/json' \
  -d '{
    "status": "APPROVED",
    "reason": ""
  }'

• status — the target status.
• reason (optional) — free text, stored against the trip. Worth sending for DECLINED and CANCELED, where it's shown to the traveler.
• saveStatus (optional, default false) — when requesting cancellation, set true to remember the current status so restore-status can bring it back.

Authorization matters here: approve and decline are limited to the trip's designated approvers (administrators can generally act in their place), hard-cancelling an already-approved trip requires an admin or super-admin token, and a personal-assistant token can only ever request cancellation, never cancel outright.

To restore a trip parked in CANCEL_REQUESTED:

curl -X POST https://api.premote.io/v1/trips/456/restore-status \
  -H 'Authorization: Bearer <token>'

Status changes and traveler emails

premote emails the traveler when a trip is submitted, approved, declined, cancelled, or cancellation is requested. APPROVED_MISSING_DATA additionally drives reminder emails until the data is supplied.

Legacy values

Two values exist in the schema and may appear on older records. Accept them; don't build on them.

This is the general rule for status handling: treat the set as open. Log and skip values you don't recognise rather than throwing, so a newly-introduced status never breaks your sync.

Recap