Updating a trip

The endpoint

PUT /trips/{id} — API Reference

curl -X PUT https://api.premote.io/v1/trips/456 \
  -H 'Authorization: Bearer <token>' \
  -H 'Content-Type: application/json' \
  -d '{
    "travelerId": 123,
    "values": {
      "start_date": "2026-09-03"
    }
  }'

• travelerId — the trip's traveler. Required.
• values — trip field values keyed by field key (snake_case). It is a partial update: keys you omit keep their stored value.

The keys are the same ones you send on creation — discover them with GET /trip-fields — API Reference. See Create a trip via the API for the full field-discovery walkthrough.

Requires an admin or personal-assistant token.

Two responses — branch on them

The same call has two outcomes, and they are not distinguished by status code. Both answer 200.

{
  "deferredForReapproval": true,
  "editRequestId": 8842
}

Which changes need re-approval

By default, only three changes open a change request:

• start_date or end_date moves — in either direction. Shortening a trip needs re-approval just as extending it does.
• workation_days increases — more days counting against the traveler's workation allowance.
• vacation_days decreases — fewer private days, so more of the trip is working time.

And only when both of these hold:

1. The trip is APPROVED, APPROVED_EDIT_PENDING or COMPLETED. A PENDING or DRAFT trip is edited in place, with no approval step.
2. Your company has an approval rule configured for that trip type (and policy). With no rule there is nobody to re-approve, so the change applies immediately.

Everything else — destination, work location, travel reason, contact person, cost centre — is applied straight away, with no re-approval, whatever the trip's status.

Unless the trip's policy re-approves every change. A policy can be configured so that any change to an approved trip goes back through the approval chain — including destination, travel reason and the answers on each stop of a multi-stop trip. On such a trip, every PUT that changes a stored value returns deferredForReapproval. This is set per policy by premote, not through the API; if you are unsure whether it applies to you, ask your premote contact — and branch on the response either way.

Resolving a deferred change

Read the open request from the full trip — GET /trips/{id} — API Reference. It arrives as tripEditRequest, an array; the open one has status: "PENDING". Each carries its approvals, so you can see how far the chain has got.

Decide it with:

POST /trips/{tripId}/change/{requestId} — API Reference

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

• ACCEPTED — the values are written to the trip, the risk assessment is re-run, and the filings are corrected. The traveler is notified.
• REJECTED — the values are discarded and the trip keeps what it had.

Either outcome returns the trip to its previous status. Only the approver on the chain's active step can decide a request.

A further edit while a request is open merges into that same request rather than opening a second one — so an integration that retries an update will not create a queue of pending changes.

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

What gets re-filed with the authorities

Changing a value does not automatically mean a new government filing. Exactly four field keys do: start_date, end_date, destination and location_abroad.

If one of them changes and a filing has already succeeded for the trip, premote withdraws the existing certificate or notification with the authority and submits a corrected one for the new period. If nothing had been filed yet, the update simply changes the trip and the filing is made once, with the new values.

location_abroad takes the same two shapes as on creation: free text, which is geocoded, or the address as separate parts, stored exactly as sent:

{
  "travelerId": 123,
  "values": {
    "location_abroad": {
      "street": "Nipvägen",
      "houseNumber": "52",
      "postalCode": "90434",
      "city": "Umeå",
      "country": "SE"
    }
  }
}

street, houseNumber, postalCode, city and country are required; houseNumberAddition and region are optional. country must equal the trip's destination — a missing part or a mismatch returns 400 naming the field (e.g. values.location_abroad.city is required).

Changes to any other field are stored on the trip, but the filing already lodged stays as it is — an A1 certificate is not re-issued because a cost centre changed.

Track the result on processRuns and their nested workflowRuns — see Compliance and risk statuses.

Do not use POST /trips/{id}/data to change an existing value

POST /trips/{id}/data — API Reference — exists to fill in what is missing, typically on a trip parked in APPROVED_MISSING_DATA. It is not an update endpoint, and using it as one fails quietly in two different ways:

• On an APPROVED trip, a key that already has a value is skipped — and you still get a 201. Your new start date is simply not written.
• It never opens a change request and never triggers a re-filing, so even where the write does land, the certificate lodged with the authority keeps the old dates.

Use PUT /trips/{id} for any change to a value that already exists.

After the update

The new dates can make fields mandatory that were not required before — a longer stay, or a destination whose authority asks for more. When that happens premote parks the trip in APPROVED_MISSING_DATA rather than filing something incomplete.

Ask what is missing with GET /processes/{tripId}/missing-data — API Reference — and supply it. The trip returns to APPROVED on its own and the filings continue; there is no status call to make. See Trip statuses.

Recap

See also

• Trip statuses
• Compliance and risk statuses
• Create a trip via the API