Ellipse Gradient for Header

Airbyte Cloud Integration Guide

Integrate Airbyte Cloud with enterprise systems through its REST API, asynchronous sync jobs, connector resources, and selected webhook notifications.

Airbyte Cloud integration options at a glance

Airbyte Cloud is primarily integrated through its REST API, which manages workspaces, sources, destinations, connections, streams, connectors, and jobs. Martini can start asynchronous connection syncs, store returned job identifiers, poll job status, and route workflows according to terminal outcomes. Airbyte also provides webhook-style notifications for selected platform events, although these do not represent universal record-level change events. Connector capabilities vary and may include SaaS APIs, databases, cloud storage, incremental replication, or change data capture. Martini can securely call the Airbyte API with bearer-token credentials, orchestrate connector operations, transform configuration data, and coordinate downstream validation, notification, and remediation workflows.

Integration pointSupported by Airbyte Cloud?Common use casesHow Martini supports it
REST APIsYesManage Workspaces, Sources, Destinations, Connections, Streams, Connectors, and Jobs; start syncs and retrieve configuration or execution status.Martini can consume the Airbyte Cloud REST API, map request and response payloads, and expose reusable workflows or APIs for Airbyte operations.
Webhooks / outbound callbacksLimitedReceive selected Airbyte platform or operation notifications, including applicable sync-related events. Coverage does not extend to every connector, stream, or source-record change.Martini can expose a receiving API or webhook-triggered workflow, then retrieve authoritative Job details from Airbyte before continuing.
Bulk / async / batch APIsLimitedStart connection syncs that execute as asynchronous Jobs and monitor their status; this is not a generic bulk-record API.Martini stores the returned Job identifier, polls with controlled intervals, applies timeouts, and routes based on terminal status.
Database / analytics accessLimitedAirbyte provides database and warehouse connectors, but capabilities are specific to each Source or Destination connector rather than a universal query interface.Martini can orchestrate connector configuration and coordinate Airbyte with database or analytical workflows where required.
AuthenticationYesAirbyte Cloud API requests use API tokens or API keys, normally sent as bearer credentials; connector authentication varies by Source or Destination.Martini stores Airbyte API credentials in protected secrets or environment configuration and keeps connector credentials separate from workflow logic.
Incremental replication and CDCLimitedIncremental sync and database CDC are available for connectors and configurations that implement them; support varies by source, edition, and stream.Martini can inspect stream and Connection configuration, validate sync modes, and avoid assuming that repeated runs are incremental.
Custom connectorsYesAirbyte supports custom connector development when a required Source or Destination is not available in the standard catalog.Martini can manage or invoke exposed custom-connector resources through the Airbyte API while connector implementation remains an Airbyte-side concern.

How Airbyte Cloud exposes data and business events

Airbyte Cloud REST APIs

Airbyte Cloud’s principal integration surface is a REST API for managing Workspaces, Sources, Destinations, Connections, Streams, Connectors, and Jobs. It supports operational automation such as provisioning resources, starting syncs, retrieving configuration, and checking execution status.

Martini implementation pattern

Martini implementation pattern: Martini workflows authenticate with an Airbyte API token, call the documented REST operations, transform responses into an internal model, and apply validation and business rules before invoking subsequent systems or workflows.

Implementation sequence

Load the Airbyte API token from protected configuration
Call the required Airbyte REST operation
Handle pagination and validate the response
Map Airbyte identifiers and configuration into the workflow model
Apply provisioning or routing business rules
Persist the result and operational metadata

Asynchronous sync Jobs

Starting an Airbyte Connection sync creates an asynchronous Job. A successful request to start the operation does not prove that data movement succeeded; the Job must be monitored through completion or failure.

Martini implementation pattern

Martini implementation pattern: a workflow starts the Connection sync, stores the returned Job identifier, polls at a controlled interval or waits for an applicable notification, and routes the process according to explicit status and timeout rules.

Implementation sequence

Identify the approved Airbyte Connection
Start the Connection sync through the REST API
Store the returned Job identifier
Poll Job status at a controlled interval
Apply timeout and terminal-state rules
Trigger downstream processing only after successful completion

Airbyte webhook notifications

Airbyte provides webhook-style notifications for selected platform events and operations. These notifications should not be treated as universal record-level events or as a webhook for every changed source record.

Martini implementation pattern

Martini implementation pattern: Martini exposes a receiving API or webhook-triggered workflow, accepts the notification, retrieves authoritative Job details from Airbyte, validates the event, and continues only when the relevant operation succeeded.

Implementation sequence

Receive the applicable Airbyte webhook notification
Validate the event and correlate its identifiers
Retrieve authoritative Job details from Airbyte
Confirm the expected Connection and terminal status
Run downstream validation or orchestration
Record the event and handle duplicate notifications

Connector-based replication

Airbyte Source and Destination connectors implement protocol-specific extraction and loading through SaaS APIs, database drivers, cloud storage APIs, incremental cursors, CDC mechanisms, or connector-specific authentication. Capabilities vary by connector.

Martini implementation pattern

Martini implementation pattern: Martini manages the Airbyte resources and orchestration layer rather than assuming a common schema across connectors. It inspects Stream and Connection configuration, isolates connector-specific mappings, and coordinates downstream processing.

Implementation sequence

Identify the required Airbyte Source and Destination connectors
Inspect supported Streams and sync modes
Create or update the Connection configuration
Start the approved replication Job
Validate connector-specific results
Route failures to remediation or operational alerting

Common Airbyte Cloud integration patterns

Pattern 1: Orchestrate scheduled Airbyte syncs

When to use this pattern

Use this pattern for nightly warehouse loads, scheduled application replication, or controlled batch processing where downstream work must begin only after Airbyte completes successfully.

Integration direction
Martini
Airbyte Cloud
Snowflake
Example Mapping
Airbyte Cloud FieldCanonical FieldTarget Field
connectionIdreplicationConnectionIdAirbyte Connection identifier
jobIdsyncExecutionIdAirbyte Job identifier
statusreplicationStatuspipeline status
finishedAtcompletedAtload completion timestamp
Martini implementation pattern

A scheduler-triggered Martini workflow retrieves the approved Connection, starts a sync, persists the Job identifier, and polls until a terminal state. It validates the outcome, applies timeout and retry rules for transient failures, and triggers Snowflake processing only after a successful Job.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • conditional routing
  • business rules
  • error handling

Pattern 2: Monitor Airbyte jobs and alert operations

When to use this pattern

Use this pattern when teams need a centralized operational view of failed, delayed, or unusually long-running Airbyte Jobs across Workspaces and Connections.

Integration direction
Airbyte Cloud
Martini
ServiceNow
Example Mapping
Airbyte Cloud FieldCanonical FieldTarget Field
jobIdexternalExecutionIdServiceNow correlation identifier
connectionIdpipelineIdServiceNow configuration item or pipeline reference
statusincidentStatusServiceNow incident state
failureReasonfailureDescriptionServiceNow work notes
Martini implementation pattern

Martini periodically retrieves Jobs and Connection status, classifies failures as transient or permanent, and applies retry or escalation rules. Failed or timed-out executions are mapped into a ServiceNow notification or incident payload, while successful executions update the operational record.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • business rules
  • error handling
  • monitoring orchestration

Pattern 3: Process supported Airbyte webhook events

When to use this pattern

Use this pattern when an applicable Airbyte platform notification can reduce polling and downstream processing should begin after a sync-related event.

Integration direction
Airbyte Cloud
Martini
ServiceNow
Example Mapping
Airbyte Cloud FieldCanonical FieldTarget Field
eventTypenotificationTypeServiceNow event type
jobIdsyncExecutionIdServiceNow correlation identifier
connectionIdpipelineIdServiceNow pipeline reference
statusprocessingStatusServiceNow event status
Martini implementation pattern

Martini receives the callback through an API or webhook-triggered workflow, validates its signature or configured event controls where applicable, retrieves current Job details from Airbyte, and prevents duplicate downstream effects using the Job identifier. Successful events can trigger quality checks; failed events can initiate remediation.

Martini capabilities used
  • API exposure
  • webhook triggers
  • API consumption
  • data mapping
  • duplicate handling
  • error handling

Pattern 4: Provision Airbyte resources for approved environments

When to use this pattern

Use this pattern when an internal platform or tenant-management process needs to create or update Airbyte Sources, Destinations, and Connections for approved environments.

Integration direction
Martini
Airbyte Cloud
Snowflake
Example Mapping
Airbyte Cloud FieldCanonical FieldTarget Field
workspaceIdairbyteWorkspaceIdAirbyte Workspace identifier
sourceNamesourceDisplayNameAirbyte Source name
destinationNamedestinationDisplayNameAirbyte Destination name
streamsselectedStreamsAirbyte Connection stream configuration
Martini implementation pattern

A Martini API or workflow accepts a validated provisioning request, searches for existing resources using stable environment keys, and creates or updates only the required Airbyte objects. Sensitive connector credentials are supplied through protected configuration, and an initial Job is started only after validation succeeds.

Martini capabilities used
  • API exposure
  • API consumption
  • data mapping
  • validation
  • conditional routing
  • secrets management
  • error handling

Applications commonly integrated with Airbyte Cloud

Airbyte Cloud commonly sits between operational applications, databases, object storage, and analytical destinations. The exact streams, fields, sync modes, and authentication requirements depend on the selected Airbyte connector and its configuration.

Application Scenario Direction Martini Pattern
Salesforce Replicate Accounts, Contacts, Leads, Opportunities, and other Salesforce data into a warehouse or operational data store for reporting and synchronization. Salesforce → Airbyte Cloud → Martini Martini provisions or monitors the Airbyte source and connection through the REST API, waits for the asynchronous Job to complete, validates the result, and routes successful or failed runs to downstream processing.
HubSpot Centralize Contacts, Companies, Deals, Tickets, and marketing data for analytics and customer-data processes. HubSpot → Airbyte Cloud → Martini A Martini scheduler or webhook-triggered workflow retrieves Airbyte Job details, applies connector-specific validation, and records or forwards successful synchronization outcomes.
NetSuite Extract Customers, Vendors, Sales Orders, Invoices, and accounting data for finance reporting and operational consolidation. NetSuite → Airbyte Cloud → Martini Martini manages the relevant Source, Destination, and Connection configuration through Airbyte’s API, protects connector credentials, and applies retry and timeout rules around sync execution.
PostgreSQL Replicate relational application data into a warehouse, lake, or another database, including CDC where the connector and configuration support it. PostgreSQL → Airbyte Cloud → Martini Martini orchestrates the PostgreSQL Source and destination Connection, checks configured streams and sync modes, and sends completion or failure information to operational systems.
Snowflake Load replicated SaaS and database data into a governed analytical warehouse. Airbyte Cloud → Snowflake → Martini Martini provisions or updates the Airbyte Destination, starts approved Connections, and performs downstream quality checks only after the Airbyte Job reaches a successful terminal state.
Google BigQuery Centralize operational data for SQL analytics, dashboards, and machine-learning workflows. Airbyte Cloud → Google BigQuery → Martini A Martini workflow coordinates Airbyte sync execution, maps Job and Stream metadata into an internal operational model, and notifies downstream owners when validation succeeds or fails.
Databricks Deliver replicated data to lakehouse tables for analytics and data engineering workloads where the applicable connector is enabled. Airbyte Cloud → Databricks → Martini Martini uses the Airbyte REST API to manage the Connection and monitors asynchronous Jobs, applying environment-specific rules before triggering subsequent lakehouse processing.
Amazon S3 Store replicated data in object storage for archival, data-lake, and downstream processing use cases. Airbyte Cloud → Amazon S3 → Martini Martini coordinates the Airbyte Destination and Connection, records identifiers and outcomes, and invokes downstream file or data-quality workflows after successful completion.

How to build a Airbyte Cloud integration in Martini

Objective

Establish authenticated communication with Airbyte Cloud and separate Airbyte API credentials from connector-specific Source and Destination credentials.

Instructions in Martini

  • Store the Airbyte API token in Martini secrets or protected environment configuration.
  • Configure the Airbyte REST API base URL and bearer authentication.
  • Use separate credentials and Workspaces for appropriate environments where required.
  • Do not place tokens or connector secrets in mappings, logs, or general workflow payloads.

Objective

Select a scheduler, incoming Airbyte webhook, or internal API request according to the timing and control requirements of the integration.

Instructions in Martini

  • Use a scheduler for periodic sync orchestration or monitoring.
  • Use a webhook-triggered workflow for applicable Airbyte platform notifications.
  • Use a Martini API when another application must request provisioning or a sync.
  • Design a polling fallback where webhook coverage is not available.

Objective

Call Airbyte resources and obtain the current Source, Destination, Connection, Stream, or Job state needed for the workflow decision.

Instructions in Martini

  • Invoke the relevant Airbyte REST operation.
  • Handle pagination for list responses according to the endpoint documentation.
  • Persist stable Airbyte identifiers and correlation keys.
  • Retrieve authoritative Job details instead of relying only on a start response or webhook payload.

Objective

Coordinate asynchronous execution, dependencies, validation, and downstream actions in a maintainable Martini workflow.

Instructions in Martini

  • Start the approved Connection sync when prerequisites are satisfied.
  • Poll Jobs at a controlled interval or process a supported notification.
  • Apply timeout, terminal-state, and duplicate-execution rules.
  • Route successful, failed, and incomplete outcomes separately.

Objective

Convert Airbyte configuration, Job metadata, and connector-specific Stream information into the canonical model required by downstream systems.

Instructions in Martini

  • Map Airbyte identifiers to stable internal correlation fields.
  • Isolate connector-specific Stream and field mappings.
  • Validate required fields and expected data types.
  • Use JSON transformations and business rules where payload structure requires it.

Objective

Ensure that provisioning, retries, notifications, and downstream processing follow environment, tenant, and operational policies.

Instructions in Martini

  • Check whether a Source, Destination, or Connection already exists before creating it.
  • Confirm that a Connection uses an approved sync mode and selected Streams.
  • Do not assume incremental replication or CDC without inspecting connector configuration.
  • Prevent a second equivalent sync when an active Job is already running.

Common Airbyte Cloud data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
WorkspaceLogical Airbyte environment containing Sources, Destinations, Connections, users, and configuration.Martini, tenant-management applications, operational databasesMartini stores the Workspace identifier in environment configuration or a controlled registry and applies workspace-specific authorization and routing.
SourceConfigured origin system from which Airbyte extracts data.SaaS applications, databases, file or object-storage systemsMartini can create, update, inspect, and validate Source configuration through the REST API while keeping credentials protected.
DestinationConfigured target system to which Airbyte writes replicated data.Snowflake, Google BigQuery, Databricks, Amazon S3, databasesMartini orchestrates Destination provisioning and validates environment-specific settings before a Connection is started.
ConnectionLinks a Source to a Destination and defines selected Streams, sync mode, schedule, and applicable processing options.Airbyte Jobs, data warehouses, databases, object storageMartini uses stable business keys and stored identifiers to find or update Connections, prevent duplicate provisioning, and trigger approved syncs.
JobRepresents execution of a Connection sync or another Airbyte operation, including status and execution metadata.Monitoring systems, notification platforms, operational databasesMartini persists the Job identifier, polls or receives a notification, interprets terminal states, and applies retry, timeout, and alerting rules.
StreamSource data stream commonly corresponding to a table, endpoint, object, or collection exposed by a connector.Destination tables, warehouse schemas, downstream transformation workflowsMartini validates Stream names, fields, cursors, primary keys, and sync modes before applying connector-specific mappings or downstream rules.

Authentication and security considerations

Bearer-token API access

Airbyte Cloud API requests use API tokens or API keys, normally sent as bearer credentials. Martini should store these values in protected secrets or environment configuration rather than mappings or source code.

Separate connector credentials

Credentials used to call the Airbyte API are distinct from credentials configured inside Airbyte Sources and Destinations. Connector authentication may use OAuth, API keys, passwords, SSH keys, cloud IAM credentials, or other connector-specific methods.

Least privilege and environment isolation

  • Use workspace and account permissions appropriate to each workflow.
  • Separate development, testing, and production credentials where practical.
  • Do not log authorization headers or connector secrets.
  • Restrict provisioning inputs that contain sensitive configuration.

Operational considerations for Airbyte Cloud integrations

Rate limits and polling

Airbyte Cloud and individual source or destination providers may impose different quotas. Use controlled polling intervals, centralized retry and backoff behavior, and clear classification of transient versus permanent failures.

Pagination and asynchronous execution

List operations may be paginated, and starting a sync creates an asynchronous Job. Workflows should process all required pages, persist Job identifiers, apply timeouts, and treat only an explicit successful terminal state as completion.

Idempotency and duplicate handling

Use stable environment or tenant keys, stored Airbyte identifiers, existence checks, and active-Job checks to prevent duplicate Sources, Destinations, Connections, syncs, and downstream effects.

Connector-specific schemas

Streams, fields, cursors, primary keys, sync modes, and deletion semantics vary by connector. Validate required fields and isolate connector-specific transformations rather than assuming a universal Airbyte schema.

Testing and observability

Test authentication, pagination, provisioning, webhook duplication, timeout behavior, connector failures, and schema changes. Monitor HTTP responses, Job status, Connection state, failure reasons, retry counts, and workflow logs.

Why use Martini instead of scripts or point-to-point integrations?

Orchestration beyond a script

Scripts can call the Airbyte API, but Martini provides a reusable workflow structure for scheduling, webhook reception, asynchronous Job polling, conditional routing, validation, and downstream coordination.

Maintainable data handling

Martini separates connector-specific mappings from canonical business models and can transform JSON payloads, apply business rules, and expose controlled APIs for internal provisioning or monitoring use cases.

Operational reliability

Centralized error handling, retries, timeouts, duplicate protection, secret management, and workflow monitoring make Airbyte operations easier to operate than isolated point-to-point scripts.

Reusable integration assets

Teams can create reusable workflows and APIs around Airbyte’s documented REST operations without requiring a dedicated vendor connector or duplicating orchestration logic across applications.

Frequently asked questions

How can Airbyte Cloud be integrated with enterprise systems?

Airbyte Cloud can be integrated through its REST API for managing Workspaces, Sources, Destinations, Connections, Streams, Connectors, and Jobs. Enterprise workflows can start asynchronous syncs, monitor Job status, use connector-based replication, and receive selected webhook-style notifications. Connector capabilities such as incremental replication or CDC depend on the specific source and configuration.

Can Martini integrate with Airbyte Cloud?

Yes. Martini can consume the Airbyte Cloud REST API, orchestrate asynchronous sync Jobs, provision or update exposed Airbyte resources, and receive applicable webhook notifications. Martini can then map results, apply business rules, validate outcomes, and coordinate downstream systems.

Do I need a connector to integrate Airbyte Cloud with Martini?

No. A dedicated Airbyte Cloud connector is not required. Martini can integrate using Airbyte Cloud’s confirmed native REST API, bearer-token authentication, asynchronous Job operations, connector resources, and applicable webhook mechanisms.

Is there any extra Lonti cost to integrate Airbyte Cloud with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Airbyte Cloud. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Airbyte, source or destination vendors, cloud infrastructure providers, or other third-party systems based on subscription, usage, and deployment model.

Which Airbyte Cloud integration methods should an enterprise use?

The REST API is Airbyte Cloud’s principal integration method for management and orchestration. Use asynchronous Job operations for starting and monitoring syncs, and use webhook-style notifications where the required event is supported. Source and Destination connector capabilities, including databases, SaaS APIs, incremental replication, and CDC, must be assessed per connector.

Are Airbyte Cloud webhooks available for every source record change?

No. Airbyte provides webhook-style notifications for selected platform or operation events, but these should not be treated as universal record-level webhooks. Source-record changes are generally discovered through connector-specific incremental sync or CDC behavior.

How does synchronization work with Airbyte Cloud?

A Martini workflow can start an Airbyte Connection sync, store the returned Job identifier, and poll or receive an applicable notification until the Job reaches a terminal state. Downstream processing should depend on successful completion, with explicit handling for timeouts, retries, failed connector runs, and duplicate triggers.

How does Martini handle Airbyte Cloud mapping, errors, and retries?

Martini maps Airbyte identifiers, Job metadata, connector-specific Stream data, and configuration into canonical downstream models. Workflows can validate required fields, distinguish transient HTTP failures from configuration or connector failures, apply controlled retries and backoff, prevent duplicate effects, and route unresolved failures to operational systems.

Related Martini documentation

Events

Workflows

Security

Operations

Orchestrate Airbyte Cloud with Martini

Use Martini to securely manage Airbyte Cloud API interactions, coordinate asynchronous sync Jobs, process applicable webhook notifications, and connect replication outcomes to enterprise workflows.

EXPLORE MARTINI
BOOK A DEMO