Paste a SharePoint or OneDrive Link Straight In — No More Manual Resolution

A share link from Dropbox or Google Drive has always worked directly as source_url — Botverse resolves it to the raw file server-side before the job runs. SharePoint and consumer OneDrive links did not get the same treatment, because their share-link formats don't serve raw bytes by default: a SharePoint modern share link renders an HTML preview page, and a plain ?download=1 param returns a 403 on some of them. That gap is closed.

What resolves now

SharePoint / OneDrive for Business modern share links, in both common shapes:

• https://tenant.sharepoint.com/:x:/g/personal/user_domain_com/TOKEN — resolved to that user's _layouts/15/download.aspx?share=TOKEN endpoint.
• https://tenant.sharepoint.com/:x:/s/SiteName/TOKEN (and /:x:/t/... for a Team site) — resolved to the equivalent /sites/ or /teams/ download.aspx endpoint.

OneDrive consumer personal share links — 1drv.ms short links and full onedrive.live.com links — are resolved through the anonymous OneDrive shares API (api.onedrive.com/v1.0/shares/u!<encoded>/root/content), which serves the file directly without a sign-in prompt.

This sits alongside the resolvers already in place for Dropbox (?dl=0 → ?dl=1), Google Drive (routing through drive.usercontent.google.com to avoid the virus-scan interstitial on files over 25 MB), and Box (?dl=1).

Where it applies

Anywhere Botverse takes a source_url, video_url, or audio_url: transcode_from_url, convert_from_url, transcribe_from_url, conform_from_url, and the per-segment url fields in conform_splice_from_url. An agent — or a person — can copy a share link straight out of SharePoint or OneDrive and hand it over as-is:

const { job_id } = await callTool("transcribe_from_url", {
  source_url: "https://contoso.sharepoint.com/:v:/g/personal/j_lee_contoso_com/EaBc123...",
  output_format: "docx",
  options: { attendees: ["Jamie Lee", "Priya Patel"] }
});
// No manual "get the direct link" step first — Botverse resolves it before fetching.

Why it needed special-casing

Unlike Dropbox and Box, where the raw-download form is a query-param flip on the same URL, SharePoint and OneDrive share links don't expose a direct-download variant in the link itself — the direct route lives on a different endpoint entirely (download.aspx for SharePoint, a separate anonymous shares API for consumer OneDrive), and the SharePoint path differs depending on whether the link is to a personal OneDrive-for-Business folder or a site/Teams library. Getting this wrong is a common failure mode for agents pulling source files out of Microsoft 365: the fetch succeeds, but what comes back is an HTML sign-in or preview page instead of the file, and the job fails pre-flight with a confusing "not a valid video/audio file" error. That failure mode is gone for these link shapes.

Full source_url resolution reference is at botverse.cloud/docs.