BigQuery

Files.com can receive partner files over SFTP, browser upload, or another supported method and place them in Google Cloud Storage for BigQuery to load. It can also distribute exports that BigQuery writes back to Cloud Storage. Files.com manages the file exchange and access around the bucket; BigQuery owns ingestion, queries, and table data.

The connection is through the bucket, rather than an SFTP endpoint inside BigQuery. Google's batch-loading guidance explains the ingestion options. This arrangement lets a sender keep its existing transfer method while the data team keeps its Google Cloud ingestion process.

Bucket Access and Delivery

Connect the bucket as a Google Cloud Storage Remote Server. Use a credential with access to the objects Files.com needs to read or write. The identity running the BigQuery job needs its own Google Cloud permissions; a Files.com user account does not grant BigQuery access to a bucket or dataset.

Choose how files reach that bucket:

Use a Mount when the bucket is already the desired working location. Use separate intake and delivery when files need preparation or a distinct source copy before publication. For buffered uploads to a mount, confirm delivery to GCS before starting a load that depends on the object.

Give each sender access to its required Files.com path. A folder arrangement can separate counterparties even when their files ultimately feed one dataset. Google Cloud IAM separately controls access made directly to the bucket.

Object Paths and Load Selection

A Files.com path and a GCS object URI describe different parts of the connection. For example, if the root of bucket partner-ingestion is mounted at Files.com folder BigQuery intake, an upload to BigQuery intake/acme/orders-2026-10-15.csv appears to a BigQuery load as gs://partner-ingestion/acme/orders-2026-10-15.csv.

Configure the load for the bucket URI and file format it actually receives. Google's CSV load reference covers schema, delimiter, header, permissions, and load options. Choose object names and prefixes that let the job select a complete delivery without also matching originals, temporary files, or a previous reporting period.

If an incoming file needs PGP decryption or a layout change, complete that work before publishing it in the loader's input location. GPG processing and Transformations are explicit configuration, rather than an automatic consequence of connecting the bucket.

Load Initiation and Verification

A file arriving in GCS does not create a BigQuery load job by itself. Configure the load or transfer process that consumes the files. Files.com Google Cloud Pub/Sub notifications can notify a configured downstream workflow of file activity; the receiving service must still select the ready object and submit the job.

Verify one complete delivery: the sender uploads with its own Files.com account, the expected object is present in GCS, and the BigQuery job loads the expected records. Review the job's result and write behavior before retrying; an append load repeated after success can duplicate business data.

Use an Expectation to detect a partner file that did not arrive on time. Files.com transfer records explain arrival and bucket delivery. BigQuery's job history establishes whether the file was parsed and loaded successfully.

Export Distribution

BigQuery can export table data to Cloud Storage. Files.com can expose that output through a mounted folder or deliver it to a partner through an Automation or Sync.

An export can produce several objects. Establish how the distribution workflow knows the export job has finished and which objects belong to it before sending the result. Watching for the first output object alone does not establish a complete export. Keep the export prefix separate from unrelated intake files so onward delivery selects the intended data.