Verify Location
Test connection to cloud storage location.
Required Role: OPERATOR or higher (useful for troubleshooting)
This endpoint runs a live rclone probe against the bucket, persists the
result to the verification history, and returns that newly-written row.
The response body is identical in shape to the records returned from
GET /verifications, so clients can use a single render path.
Success response (200 OK):
{
"id": "...",
"location_id": "...",
"verified": true,
"bucket_exists": true,
"can_list": true,
"can_read": true,
"can_write": true,
"can_delete": false,
"region": "us-east-1",
"error_code": null,
"error_message": null,
"vault_field_name": null,
"vault_reference": null,
"vault_type": null,
"created_at": "2026-04-11T02:00:00Z"
}
Three-state permissions: true = probe succeeded, false = probe
failed, null = probe not run (e.g. empty bucket, delete skipped
because write failed).
Client error (400 Bad Request): Returned for user/configuration
errors (invalid credentials, bucket not found, access denied). The body
shape is the same as the success response, with verified=false and
error_code / error_message populated.
External vault resolution error (400 Bad Request): When 1Password /
Doppler / Infisical secret resolution fails, error_code is one of
VAULT_FIELD_NOT_FOUND, VAULT_ITEM_NOT_FOUND, VAULT_ACCESS_DENIED,
VAULT_INVALID_REFERENCE, VAULT_CONNECTION_ERROR,
VAULT_SDK_NOT_INSTALLED, or VAULT_UNKNOWN. The vault_field_name,
vault_reference, and vault_type fields identify exactly which
secret failed to resolve.
Server error (500 Internal Server Error): Returned only for truly unexpected bugs. Expected failure modes (vault errors, connector build errors, rclone errors) are caught inside the service layer, persisted to the verification history, and returned as 400 responses with a normal body shape.
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Response
Successful Response
A single verification record.
Used as the response body for both POST /verify (the record that was
just created) and GET /verifications (paginated history). Clients get
one consistent shape for "what happened during a verification."