How to Connect Salla to BigQuery: Complete Integration Guide

Choose a supported connection path

A Salla-to-BigQuery workflow needs a source extraction method, a destination dataset and a repeatable load. You can begin with a store export, build an API pipeline, or use a provider that demonstrates the exact entities and destination you require.

AKM includes Salla integration code and a BigQuery Data Hub option. Those are separate capabilities: confirm that your required Salla entities are supported in the selected export workflow before assuming turnkey synchronization.

Prerequisites

• Authorized Salla store access and the required read permissions.
• A Google Cloud project and a BigQuery dataset in an appropriate location.
• A revenue policy covering currency, tax, shipping, discounts, refunds and cancellations.
• An owner for token renewal, failed loads and source-schema changes.

Use Salla's platform documentation for current API requirements. Keep credentials out of scripts and source control. Grant only the permissions needed for the selected dataset and load jobs.

Option 1: Start with a manual export

1. Export a completed period using the store's available reporting tools.
2. Inspect UTF-8 encoding, dates, currency units and the fields supplied.
3. Define a BigQuery schema rather than relying blindly on automatic detection.
4. Load a staging table and compare counts and revenue with the source report.
5. Replace the same reporting period on replay to avoid duplicate uploads.

This is a useful pilot. It does not automatically capture subsequent order changes; refresh exports when refunds or cancellations affect the period.

Option 2: Build a recurring API pipeline

1. Authorize a supported Salla app and paginate through the required resources.
2. Backfill a limited date range before attempting full history.
3. Use supported order webhooks or re-fetch changed records. Verify incoming webhooks using Salla's documented mechanism.
4. Merge current orders using store ID plus order ID. Keep event or version history separately if you need an audit trail.
5. Record run status and latest successful refresh. Retry safely and respect source limits.

Do not use order ID plus update timestamp as the key of a current-order table: that can preserve multiple versions and inflate revenue. That composite key belongs in a history table with appropriately defined queries.

An illustrative validation example

If an order originally recorded at SAR 300 is fully refunded, the next successful refresh should reflect that change under your chosen revenue policy. Replaying the load must not create another SAR 300 sale.

Test this behavior with an authorized sample or non-production fixture. Also verify Arabic product names, line-item joins and duplicate webhook delivery.

Connect reporting after reconciliation

BigQuery can feed Looker Studio. Build views that state what revenue means and show source freshness. Comparing daily store revenue with ad spend is useful, but individual campaign attribution requires separately collected journey identifiers and a documented model.

Review AKM integrations for the available source workflow and confirm destination coverage with your account. Start with one reconciled period before expanding to recurring reporting.