Feature request: asynchronous (job-based) export for exportToPst / export-to-ZIP endpoints

[JonahM]

Please consider separating file generation from file transfer on the export endpoints. Today a single POST both generates the export server-side and streams it back on one synchronous 200. For large exports this holds the HTTP request open for the entire generation, which is painful to automate against. I'd like an opt-in async mode: the POST kicks off a background export, returns immediately with a job handle I can poll, and I download the result once it's complete.

Current behavior
Endpoints such as:

• POST /v8/RestoreSessions/{restoreSessionId}/organization/mailboxes/{mailboxId}/exportToPst

• the equivalent item / folder export-to-PST actions, and the OneDrive / SharePoint export-to-ZIP actions

build the whole PST (or a ZIP of split PSTs) into a temp folder on the VB365 server before sending response headers, then transfer it as application/octet-stream / application/zip under a 200. The docs already note that a partial download can be resumed by re-issuing the request with a Range header (served from that temp folder), and the restore session exposes an Export event with Running / Success / Warning / Failed / Cancelled states.

Problem / impact

Because the connection stays idle until generation finishes (no bytes, no headers), the synchronous model fights every layer between client and server:

• Time-to-first-byte exceeds normal timeouts. A multi-GB mailbox can take many minutes to build before the first byte; HTTP clients, reverse proxies, and load balancers time the "read" out and abort what is actually a healthy export.

• Automation/pipelines are held hostage. CI/CD jobs, message-queue workers, and orchestration tasks must block a worker (and often keep a broker delivery un-acked) for the full generation, tripping consumer/idle timeouts and starving other work.

• No progress or control. Until the stream starts there's no signal whether the server is still working or wedged, and no clean way to cancel.

Proposed enhancement

An opt-in asynchronous flavor, ideally negotiated so existing integrations are unaffected — e.g. a Prefer: respond-async request header (RFC 7240) or an ?async=true query parameter:

• Kick off: the POST validates and enqueues the export, then returns 202 Accepted immediately, with a Location header pointing at an export-job/operation resource (the existing restore-session Export event would be a natural fit to reuse).

• Poll: GET that resource for status (Running → Success / Failed / Cancelled), ideally with progress and the final media type (PST vs split-ZIP) once known.

• Download: on Success, GET the generated file from a stable URL — keeping the existing Range support so the download itself remains resumable.

• (Optional) Clean up: a DELETE on the job to release the temp file explicitly, with TTL-based cleanup as a backstop.

I imagine this flow could be somewhat similar to how VSPC handles things like tenant/resource creation with returning an AsyncActions endpoint/URL in the initial response.