Which direction does data move between IFS Cloud and BigQuery?

The integration flows from IFS Cloud into BigQuery. ml-connector reads invoices, purchase orders, GL entries, suppliers, and payment records from IFS on a polling schedule and writes flattened records into BigQuery tables. BigQuery is the data sink; there is no flow back into IFS.

Does IFS Cloud have webhooks, or does this integration poll?

IFS Cloud does not offer standard webhook subscriptions. Event Actions exist but require manual per-customer configuration and are not API-driven. ml-connector uses pull-based polling on a schedule you set, filtering by timestamp or state fields to capture new and modified records since the last poll.

How does ml-connector handle IFS rate limits and token expiry?

IFS rate-limits to approximately 1000 requests per minute per tenant. ml-connector respects this by tracking request pace, backing off with exponential jitter when HTTP 429 is returned, and retrying. OAuth tokens from IFS expire after 60 minutes; ml-connector refreshes them automatically before the token expires so polling is never interrupted.

IFS CloudGoogle BigQuery

IFS Cloud and Google BigQuery integration

IFS Cloud runs manufacturing, procurement, and finance across your enterprise. Google BigQuery stores and analyzes structured data at scale in the cloud. Connecting the two lets you load operational records from IFS into BigQuery on a schedule, building a data warehouse of invoices, purchase orders, and journal entries for analytics, reporting, and audit trails. ml-connector handles the different APIs and authentication methods on each side.

How IFS Cloud works

IFS Cloud exposes suppliers, purchase orders, supplier invoices, GL accounts, cost centers, journal entries (vouchers), and payment data through OData v4 REST APIs, accessed via https://<tenant>.ifs.cloud base URLs that are unique to each customer. Authentication uses OAuth2 Client Credentials grant against a tenant-specific token endpoint, with a token lifetime of approximately 60 minutes. IFS does not offer standard webhook subscriptions; Event Actions require manual per-customer configuration and are not API-driven, so the recommended pattern is pull-based polling of OData with filters on timestamps and state fields. Requests are rate-limited to approximately 1000 per minute per tenant, and mutation operations (PATCH, certain POST) require ETag concurrency headers read from the source record first.

How Google BigQuery works

Google BigQuery is a serverless cloud data warehouse on Google Cloud Platform accessed via REST API over HTTPS. It authenticates with a Service Account JWT Bearer token, obtained by signing a JWT with the service account private key and exchanging it for a short-lived access token valid for 3600 seconds. BigQuery stores data in datasets and tables with no pre-defined vendor or invoice schemas; the customer defines table structures. It has no native webhook or event subscription API, so all data access is pull-based. Streaming inserts into BigQuery use best-effort deduplication via insertId, and the Storage Read API is preferred for large-volume reads over the standard tabledata list endpoint. Service accounts require bigquery.dataEditor and bigquery.jobUser roles minimum for read-write access.

What moves between them

The integration flows from IFS Cloud into Google BigQuery. ml-connector polls IFS OData on a schedule you set, reading supplier invoices, purchase orders, GL entries, cost center mappings, and payment records. Each record is flattened and written into BigQuery tables with columns for the IFS company code, dimensions, amounts, dates, and status. Reference data such as suppliers and GL accounts are kept current in separate tables so analytics queries can join operational records to master data. Because both systems are cloud-based and BigQuery is append-only for this pattern, records are typically inserted rather than updated; timestamp filtering ensures new and modified records are captured on each poll cycle.

How ml-connector handles it

ml-connector stores the IFS OAuth2 client credentials and the BigQuery service account private key encrypted at rest. On each poll interval, it obtains a fresh OAuth token from the IFS tenant's token endpoint and makes authenticated OData requests to read invoices, POs, and GL entries filtered by timestamp or state. IFS rate-limits to 1000 requests per minute, so ml-connector tracks request pace, backs off with jitter when HTTP 429 is returned, and retries. IFS OData requires ETag concurrency headers on mutation operations; ml-connector reads the ETag from any record before attempting updates. The flattened records are collected into batches and inserted into BigQuery tables via streaming inserts, using the insertId field to deduplicate if the same record is polled twice. BigQuery access tokens expire after 3600 seconds; ml-connector refreshes them before expiry. The full audit trail is maintained in a Postgres table local to ml-connector, so any record can be replayed if a downstream BigQuery load fails.

A real-world example

A mid-sized manufacturer uses IFS Cloud for procurement, manufacturing, and finance across three plants. Finance and supply chain teams need visibility into invoice aging, PO spend by cost center, and payment status in a data warehouse they can query with SQL. Before the integration, finance exported invoices and POs from IFS each week in Excel, manually joined them to supplier master data, and loaded the results into a homegrown spreadsheet-based analytics system. With IFS Cloud connected to BigQuery, invoices, purchase orders, and GL entries flow into analytics tables automatically on a daily schedule. The supply chain team now runs queries on top-spending suppliers, invoice aging by cost center, and payment performance without manual data entry, and the audit trail shows exactly when each invoice entered the warehouse.

What you can do

Load IFS Cloud invoices, purchase orders, GL entries, and payment records into BigQuery tables on a schedule you define.
Map IFS company codes, cost centers, and GL account dimensions to denormalized BigQuery columns so analytics queries can group and filter by business structure.
Refresh IFS OAuth tokens automatically when they expire and handle the 1000-request-per-minute rate limit with exponential backoff.
Store both IFS and BigQuery credentials encrypted and maintain a full audit trail so any record can be replayed if a load fails.
Flatten nested OData structures and deduplicate streaming inserts into BigQuery so your data warehouse stays clean and query-ready.

Questions

Which direction does data move between IFS Cloud and BigQuery?: The integration flows from IFS Cloud into BigQuery. ml-connector reads invoices, purchase orders, GL entries, suppliers, and payment records from IFS on a polling schedule and writes flattened records into BigQuery tables. BigQuery is the data sink; there is no flow back into IFS.
Does IFS Cloud have webhooks, or does this integration poll?: IFS Cloud does not offer standard webhook subscriptions. Event Actions exist but require manual per-customer configuration and are not API-driven. ml-connector uses pull-based polling on a schedule you set, filtering by timestamp or state fields to capture new and modified records since the last poll.
How does ml-connector handle IFS rate limits and token expiry?: IFS rate-limits to approximately 1000 requests per minute per tenant. ml-connector respects this by tracking request pace, backing off with exponential jitter when HTTP 429 is returned, and retrying. OAuth tokens from IFS expire after 60 minutes; ml-connector refreshes them automatically before the token expires so polling is never interrupted.

Connect IFS Cloud and Google BigQuery

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started