browser_profile_id so the agent starts a session already authenticated instead of signing in from scratch every run.
Where a vault injects individual secrets at the moment the agent fills a login form, a profile restores the entire logged-in state up front. Reach for a vault when the agent should sign in with credentials; reach for a profile to carry an existing, already-authenticated session forward.
Profiles belong to your organization: any agent in the org can load one, and they persist across sessions until you delete them.
Uploading a profile
The archive is a.zip of a browser’s user-data directory — for Chrome, ~/Library/Application Support/Google/Chrome (macOS) or ~/.config/google-chrome (Linux). It can hold cookies and saved logins, so treat it as a secret.
A profile archive can be large, so the bytes are uploaded directly to object storage through a presigned URL and never pass through the Agent API. The flow is three steps:
Initiate the upload
Call
POST /initiate-upload. It returns a profile_id, a presigned upload_url, and the upload_fields you must include with the upload.Upload the archive to storage
POST your profile .zip to upload_url as multipart/form-data, including every entry from upload_fields. This request goes to object storage, not to the Agent API. The archive must be application/zip and at most 1 GB; storage rejects anything else.The presigned
upload_url and upload_fields are passed through to object storage exactly as returned, so do not modify them. They expire after upload_expires_in seconds, so upload promptly after initiating.Complete the upload
Call
POST /{profile_id}/complete-upload with the profile metadata (name, browser_name, browser_version) within 1 day of uploading. The platform verifies the uploaded archive and creates the profile record. Until you complete it, the upload is held as pending and is deleted automatically after 1 day.