Skip to main content
Enterprise PortalSetting Up Cloud Routing for Direct Delivery

Setting Up Cloud Routing for Direct Delivery

Cloud Routing is a Scale tier feature that pushes every delivery directly into your own storage instead of making your team download files through the portal. You configure one dedicated endpoint, and the weekly JSONL file lands in your bucket on delivery day, ready for your warehouse loader or ETL pipeline to pick up.

Amazon S3

Provide your bucket ARN, the target object prefix (for example, vidscore/weekly/), and an IAM role ARN that VidScore assumes when writing. You also generate an external ID, a random string we include on every sts:AssumeRole call so your role trust policy can verify the request actually came from us. This prevents the confused deputy problem where another AWS account could trick us into writing to your bucket. The role only needs s3:PutObject on the prefix, nothing broader. Keep the bucket in the same region as your data warehouse to avoid cross-region egress.

Google Cloud Storage

Grant the Storage Object Creator role to [email protected] on your target bucket, then tell us the bucket name and object prefix. No keys to rotate, no secrets to store on your side. We authenticate with Google using our own workload identity and write objects under the prefix you specify.

Azure Blob Storage

Provide the storage account name, container name, and a SAS token scoped to the container with write and create permissions. Set the SAS expiry to cover your contract term and rotate it before it expires. We only need to create new blobs, not list, read, or delete, so grant the minimum scope.

HTTPS webhook

Instead of writing to object storage, we POST the delivery payload to a URL you control. Every request is signed with an HMAC-SHA256 signature in the X-VidScore-Signature header using a shared secret you generate in the portal. Verify the signature before trusting the payload. We expect a 2xx response within 30 seconds. If the request fails or times out, we retry three times with exponential backoff (1 min, 5 min, 25 min), then surface the failure in your activity feed.

One destination per account

The Scale tier includes one active Cloud Routing destination. If you need the same feed in multiple warehouses or regions, own that fan-out in your own pipeline. Land the file in one place, then replicate from there.

Detailed reference

What you can expect

  • S3 with assumed IAM role and external ID
  • Google Cloud Storage with service account grant
  • Azure Blob with SAS token scoped to a container
  • HTTPS webhook with HMAC-signed POST requests
  • One active destination per Scale tier account

Limits

  • Cloud Routing is not available on Starter or Growth tiers
  • Fan-out to multiple warehouses is not supported, handle it in your own pipeline
  • Custom file formats beyond the standard JSONL feed are not supported
  • Real-time streaming is not supported, deliveries still run on the weekly cadence

If something looks off

If a delivery fails to write and retries are exhausted, check the activity feed for the specific error. Permission errors usually mean a role or grant was revoked. Network errors on webhooks usually mean the endpoint moved or the TLS certificate expired. Contact [email protected] if you need help reading the error payload.

Important context

Cloud Routing proves access through infrastructure trust, not shared secrets. For S3, the external ID and role trust policy are the security boundary. For GCS, it is the IAM grant on your service account. Rotate Azure SAS tokens and webhook HMAC secrets on your own schedule, we do not force expiry.

Last updated 2026-04-14

Did this help?

Related articles

Still need help?

We're here if you need us.