Ellipse Gradient for Header

Fivetran Integration Guide

Integrate Fivetran with enterprise systems through its REST API, selected operational webhooks, asynchronous connector operations, and destination data interfaces.

Fivetran integration options at a glance

Fivetran’s primary integration surface is its REST API, which can manage connectors, destinations, groups, users, configuration, and synchronization operations. Fivetran also provides webhook-style notifications for selected operational events, such as connector or sync status changes. Connector synchronization is asynchronous and may use incremental extraction, change tracking, or other source-specific techniques. Martini can consume the REST API, receive supported webhook notifications, poll operation status, and orchestrate provisioning, monitoring, and catalog workflows. API key and API secret credentials are supplied through HTTP Basic Authentication, while source and destination credentials remain connector-specific. Replicated data is normally queried through the configured destination’s native database or analytics interface.

Integration pointSupported by Fivetran?Common use casesHow Martini supports it
REST APIsYesManage connectors, destinations, groups, users, configuration, testing, status, and supported synchronization operations.Martini can consume the Fivetran REST API, map request and response data, expose controlled wrapper APIs, and orchestrate multi-step operations.
Webhooks and outbound callbacksLimitedReceive selected connector or synchronization status notifications. Coverage is operational rather than a universal stream of source-row changes.Martini can receive supported Fivetran webhook notifications, validate payloads, apply idempotency rules, and start asynchronous workflows.
Bulk, asynchronous, and batch operationsLimitedFivetran connectors execute asynchronous synchronization jobs using connector-dependent incremental, change-tracking, or other extraction methods.Martini can initiate supported operations, poll status, handle timeouts and retries, and distinguish accepted, running, successful, failed, paused, and disabled states.
AuthenticationYesThe Fivetran REST API uses an API key and API secret through HTTP Basic Authentication; connector credentials vary by source and destination.Martini can store credentials in secured environment configuration and apply them to API requests without exposing them in workflows, mappings, or logs.
Database and analytics accessLimitedFivetran loads replicated data into configured warehouses, databases, lakes, or storage destinations; querying is normally destination-native.Martini can access a destination separately through its available database or API interface, but does not treat the Fivetran REST API as a SQL query endpoint.
File and attachment APIsNot confirmedFivetran supports some file- and storage-oriented connectors, but its platform API is not a general file-upload or attachment API.Martini can use the relevant Fivetran connector or the source system’s own file API when file contents must be transferred.
GraphQL APIsNot confirmedNo official Fivetran GraphQL API was identified in the reviewed documentation.Martini should use the documented Fivetran REST API rather than assume GraphQL availability.
SOAP APIsNoThe documented Fivetran platform API is REST-based; no current Fivetran SOAP API was identified.Martini can consume REST endpoints and connect separately to other SOAP systems when required by the surrounding architecture.

How Fivetran exposes data and business events

Fivetran REST APIs

Fivetran provides a REST API for managing connectors, destinations, groups, users, configuration, testing, status, and supported synchronization operations. The API is the primary integration mechanism for platform management.

Martini implementation pattern

Martini implementation pattern: Martini stores the Fivetran API key and secret securely, consumes the required REST endpoints, maps responses into internal models, and orchestrates dependent actions such as validation, provisioning, status publication, and incident handling.

Implementation sequence

Receive a provisioning, management, or monitoring request
Authenticate with the Fivetran REST API using HTTP Basic Authentication
Retrieve or validate the relevant connector, group, or destination
Map the request into Fivetran fields and invoke the supported operation
Transform the response into the internal operational model
Persist identifiers, status, and audit information

Fivetran Webhooks

Fivetran supports webhook-style notifications for selected operational events, including connector or synchronization status changes. These notifications are not a universal row-level event stream for every source record.

Martini implementation pattern

Martini implementation pattern: Martini exposes an API or webhook-triggered workflow, validates the notification, records an event key, and moves longer processing into an orchestrated workflow that updates operational systems.

Implementation sequence

Receive the selected Fivetran webhook notification
Validate the event structure and authentication requirements
Check the event against stored processing state
Retrieve current connector or sync details when needed
Map the status to an incident, dashboard, or catalog model
Acknowledge the notification and record the processing result

Asynchronous connector synchronization

Fivetran connector synchronization runs asynchronously and may use incremental extraction, change tracking, log-based replication, cursor-based extraction, or other connector-specific techniques.

Martini implementation pattern

Martini implementation pattern: Martini starts or requests a supported connector operation, then polls with bounded intervals or reacts to a supported webhook. It applies timeout, retry, idempotency, and terminal-state rules rather than treating an accepted request as completion.

Implementation sequence

Submit or request the supported connector operation
Store the connector and internal request identifiers
Wait according to a bounded polling or notification strategy
Retrieve the current synchronization status
Apply success, failure, paused, or timeout rules
Publish the final outcome and retain an operational audit record

Fivetran destination access

Fivetran loads replicated data into configured destinations, while querying that data normally uses the destination’s native SQL, analytics, storage, or API interface rather than the Fivetran REST API.

Martini implementation pattern

Martini implementation pattern: Martini manages Fivetran delivery metadata through the Fivetran API and connects separately to a supported destination when a workflow must inspect or process replicated data.

Implementation sequence

Identify the configured Fivetran destination
Confirm the destination interface and required credentials
Retrieve connector or schema metadata from Fivetran
Connect to the destination through its native interface
Map and validate the replicated data needed by the workflow
Record processing status and destination query results

Common Fivetran integration patterns

Pattern 1: Provision Fivetran connectors from an internal request

When to use this pattern

Use when a data platform, governance, or service-management process needs controlled creation or modification of Fivetran pipelines. Validation prevents duplicate connectors and ensures that source, destination, owner, and environment settings are complete.

Integration direction
ServiceNow
Martini
Fivetran
Example Mapping
Fivetran FieldCanonical FieldTarget Field
sourcesourceSystemFivetran connector source
destinationdestinationIdFivetran destination
ownerdataOwnerconnector owner metadata
environmentdeploymentEnvironmentgroup or connector configuration
Martini implementation pattern

A Martini API receives the request, validates required fields and permissions, searches for an existing connector using a stable internal request ID, maps approved settings, and calls the Fivetran REST API. It returns the connector identifier and provisioning state, while retrying transient failures without creating duplicates.

Martini capabilities used
  • APIs
  • workflows
  • API consumption
  • data mapping
  • business rules
  • secrets management
  • error handling

Pattern 2: Monitor connector synchronization and create incidents

When to use this pattern

Use when data operations teams need prompt notification of failed, delayed, paused, or disabled synchronization. Supported webhook events can reduce polling, while scheduled status checks provide coverage for operational conditions that require periodic review.

Integration direction
Fivetran
Martini
ServiceNow
Example Mapping
Fivetran FieldCanonical FieldTarget Field
connector_idpipelineIdServiceNow configuration item
sync_statuspipelineStatusincident state and severity
failure_messagefailureReasonincident description
last_successful_synclastSuccessAtoperational record
Martini implementation pattern

Martini receives a selected webhook or retrieves connector status on a schedule, normalizes the status, applies severity and ownership rules, and creates or updates a ServiceNow incident. An idempotency key based on connector and event state prevents duplicate incidents; transient API errors use bounded retries.

Martini capabilities used
  • webhook consumption
  • scheduler triggers
  • workflow orchestration
  • data mapping
  • business rules
  • idempotency
  • error handling

Pattern 3: Synchronize Fivetran pipeline metadata to a data catalog

When to use this pattern

Use when governance teams need a current inventory of groups, connectors, destinations, ownership, environment classification, and operational state. The pattern is suited to scheduled synchronization because metadata collections are paginated and can change over time.

Integration direction
Fivetran
Martini
ServiceNow
Example Mapping
Fivetran FieldCanonical FieldTarget Field
connector_idassetIdcatalog asset identifier
group_idorganizationalUnitcatalog domain
destinationtargetPlatformcatalog destination
statusoperationalStatusasset status
Martini implementation pattern

A scheduled Martini workflow follows Fivetran pagination, retrieves the relevant collections, maps them into a canonical catalog model, and upserts records using stable Fivetran identifiers. It detects removed or changed resources, validates required fields, and records partial failures for retry.

Martini capabilities used
  • scheduler triggers
  • REST API consumption
  • pagination handling
  • mapping
  • validation
  • business rules
  • monitoring

Pattern 4: Coordinate replicated data processing at a destination

When to use this pattern

Use when a downstream workflow must begin after Fivetran has completed a connector synchronization and then inspect or process data in the configured warehouse or database. The destination query remains separate from Fivetran’s management API.

Integration direction
Fivetran
Martini
Snowflake or Google BigQuery
Example Mapping
Fivetran FieldCanonical FieldTarget Field
connector_idpipelineIdprocessing pipeline key
sync_statusreplicationStaterun eligibility
schema_namesourceSchemadestination schema
last_successful_syncwatermarkprocessing checkpoint
Martini implementation pattern

Martini waits for a supported successful sync state through webhook or polling, validates the destination and checkpoint, then uses the destination’s native interface to process replicated data. It stores checkpoints, applies schema and required-field rules, and routes query or transformation failures for retry or review.

Martini capabilities used
  • workflows
  • webhook consumption
  • API consumption
  • database access
  • data mapping
  • checkpointing
  • error handling

Applications commonly integrated with Fivetran

Fivetran commonly sits between operational applications or databases and analytical destinations. Martini can complement that architecture by managing Fivetran operations, coordinating status workflows, and publishing operational information to enterprise applications.

Application Scenario Direction Martini Pattern
Salesforce Replicate Accounts, Contacts, Leads, Opportunities, and other Salesforce data into a warehouse or lake for analytics. Salesforce → Fivetran → Snowflake or BigQuery Use Fivetran for source replication and Martini to provision or monitor the connector, validate status notifications, and publish operational outcomes to data operations teams.
HubSpot Centralize Contacts, Companies, Deals, and marketing activity for reporting and analysis. HubSpot → Fivetran → Cloud data warehouse Orchestrate connector configuration through the Fivetran REST API, monitor asynchronous syncs, and apply source-specific validation before updating an internal catalog.
NetSuite Replicate Customers, Vendors, Items, transactions, and accounting data for analytics and reconciliation. NetSuite → Fivetran → Snowflake or BigQuery Expose a controlled Martini API for provisioning requests, map approved source and destination settings to Fivetran, and route failures to operational workflows.
Jira Load Issues, Projects, Users, and work-management activity into reporting or operational analytics. Jira → Fivetran → Cloud data warehouse Schedule connector-status checks, normalize Fivetran results, and update data-platform ownership or support records when synchronization falls outside expected conditions.
Snowflake Receive replicated application and database data for analytics, transformation, and governed reporting. Fivetran → Martini → Snowflake Use Martini for Fivetran destination and connector lifecycle orchestration, then access Snowflake separately when downstream workflows need destination-native SQL or metadata.
Google BigQuery Store replicated data for SQL analytics and machine-learning workloads. Fivetran → Martini → Google BigQuery Monitor Fivetran delivery status through API or supported webhooks and use destination-specific access for workflows that need to inspect replicated data.
Amazon Redshift Load operational data into an AWS-based analytical warehouse. Fivetran → Martini → Amazon Redshift Coordinate connector operations and incident handling in Martini while using the destination’s native database interface for any required data queries.
ServiceNow Track connector failures, provisioning requests, ownership, and data-platform operational work. ServiceNow → Martini → Fivetran Receive requests or status events in Martini, validate and map them to Fivetran REST API operations, and create or update ServiceNow incidents without duplicating records.

How to build a Fivetran integration in Martini

Objective

Establish authenticated access to Fivetran and protect credentials across environments.

Instructions in Martini

  • Store the Fivetran API key and secret in Martini secured environment configuration.
  • Use HTTP Basic Authentication for Fivetran REST API calls.
  • Confirm API-user permissions for connector, destination, group, user, and synchronization operations.
  • Keep source and destination credentials separate from Fivetran REST API credentials.

Objective

Select the event or schedule that starts the integration workflow.

Instructions in Martini

  • Use a Martini API for provisioning or on-demand operations.
  • Use a webhook-triggered workflow for supported Fivetran operational notifications.
  • Use a scheduler for connector monitoring and metadata synchronization.
  • Avoid treating Fivetran webhooks as a universal source-record event stream.

Objective

Collect the current Fivetran resource or synchronization state required by the workflow.

Instructions in Martini

  • Call the relevant Fivetran REST endpoint.
  • Follow pagination for collection responses.
  • Retrieve current connector or sync details after receiving a notification.
  • Use the destination’s native interface when querying replicated data.

Objective

Coordinate validation, API calls, asynchronous status handling, and downstream actions.

Instructions in Martini

  • Model accepted, in-progress, successful, failed, paused, and disabled states.
  • Store connector IDs, request IDs, checkpoints, and processed event keys.
  • Apply bounded polling intervals, timeouts, and retry policies.
  • Route long-running processing to asynchronous workflow execution where appropriate.

Objective

Convert Fivetran responses and operational events into stable enterprise models.

Instructions in Martini

  • Map connector, destination, group, sync, schema, and status fields to canonical names.
  • Validate required identifiers and ownership fields.
  • Normalize timestamps, status values, and failure details.
  • Handle source-specific connector behavior and schema variation explicitly.

Objective

Control provisioning, alerting, ownership, and duplicate prevention.

Instructions in Martini

  • Check permissions and environment rules before provisioning.
  • Search for existing connectors before creation.
  • Set incident severity from connector status and business impact.
  • Use stable keys to prevent duplicate incidents, catalog entries, or notifications.

Common Fivetran data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
ConnectorsRepresent configured pipelines that extract from a source and load into a destination.ServiceNow, internal data catalogs, operational dashboardsMartini can create, retrieve, update, validate, and monitor connectors through the Fivetran REST API, subject to permissions.
DestinationsDefine warehouses, databases, lakes, or storage targets receiving replicated data.Snowflake, Google BigQuery, Amazon Redshift, internal catalogsMartini can map destination metadata, coordinate provisioning workflows, and store identifiers and status in enterprise systems.
GroupsOrganize connectors and destinations for account, team, environment, or ownership management.Data catalogs, governance systems, ServiceNowMartini can retrieve and synchronize group ownership and environment metadata using paginated API workflows.
UsersRepresent Fivetran users and account or group access where permitted.Identity governance, ServiceNow, internal access recordsMartini can read or manage user-related information through authorized REST API operations and apply access rules.
SyncsRepresent connector synchronization operations, statuses, and operational results.Incident management, observability systems, data-operations dashboardsMartini can initiate supported operations, poll status, process selected webhook notifications, and publish normalized outcomes.
Schemas and tablesDescribe structures replicated from source systems into destinations and affected by schema changes.Data catalogs, governance platforms, destination databasesMartini can map available metadata and apply validation or alerting, while treating source-specific schema behavior as variable.

Authentication and security considerations

Fivetran REST API authentication

The Fivetran REST API uses an API key and API secret supplied through HTTP Basic Authentication. Permissions are determined by the associated Fivetran user or account.

Credential separation

Source and destination credentials are connector-specific and may use OAuth, API keys, database credentials, service accounts, cloud credentials, or SSH keys. They should not be confused with Fivetran REST API credentials.

  • Store API keys and secrets in Martini secured environment configuration.
  • Use separate credentials and configuration for development, staging, and production where appropriate.
  • Do not expose credentials in workflow definitions, mappings, logs, or client-facing responses.
  • Verify permissions before exposing connector-management operations through a Martini API.

Operational considerations for Fivetran integrations

Rate limits and pagination

Fivetran applies REST API usage limits, and collection endpoints can be paginated. Martini workflows should use controlled schedules, bounded retries, backoff, caching for stable metadata, and complete pagination handling.

Asynchronous operations

An accepted API request does not prove that synchronization completed. Track in-progress, successful, failed, paused, disabled, and timed-out states through polling or supported notifications.

Idempotency and schema changes

Store connector IDs, internal request IDs, checkpoints, and processed event keys. Validate required fields and plan for source-specific changes to schemas, fields, deletion behavior, pagination, rate limits, and authentication.

Testing and monitoring

  • Test connector-specific behavior before production rollout.
  • Verify webhook payload validation and acknowledgement behavior.
  • Monitor workflow logs and retain operational audit information without sensitive credentials.
  • Use destination-native testing for workflows that inspect replicated data.

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

Orchestration beyond individual API calls

Scripts can call the Fivetran REST API, but Martini provides a maintainable workflow model for provisioning, polling, webhook processing, validation, mapping, retries, and downstream updates.

Reusable enterprise controls

Martini can expose controlled APIs, centralize secured configuration, apply environment-specific business rules, and reuse integration assets across connector-management and monitoring workflows.

Operational reliability

  • Handle asynchronous states instead of assuming immediate completion.
  • Apply bounded retries, timeouts, pagination, and idempotency controls.
  • Publish normalized status to ServiceNow, catalogs, dashboards, or other enterprise systems.
  • Keep Fivetran platform management separate from destination-native data processing.

Frequently asked questions

How can Fivetran be integrated with enterprise systems?

Fivetran can be integrated through its REST API, selected operational webhooks, asynchronous connector operations, and destination-native database or analytics interfaces. The REST API manages connectors, destinations, groups, users, configuration, and supported synchronization operations. Webhooks cover selected platform or sync events rather than every source-row change.

Can Martini integrate with Fivetran?

Yes. Martini can consume the Fivetran REST API, receive selected Fivetran webhook notifications, orchestrate asynchronous connector operations, map responses, and publish status to enterprise systems. No native Martini Fivetran connector is documented in the supplied research.

Do I need a connector to integrate Fivetran with Martini?

No dedicated Fivetran connector is required. Martini can integrate using Fivetran’s confirmed native REST API, selected webhook notifications, HTTP Basic Authentication, and destination-specific interfaces where required.

Is there any extra Lonti cost to integrate Fivetran with Martini?

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

Which Fivetran integration methods should an enterprise use?

Use the Fivetran REST API as the primary method for connector, destination, group, user, configuration, and status management. Use supported webhooks for selected operational events, scheduled polling for coverage and reconciliation, and the destination’s native database or analytics interface for replicated data access.

Are Fivetran events or webhooks available?

Fivetran supports webhook-style notifications for selected connector and synchronization events. They should not be treated as a universal row-level event stream for every source application. Martini can validate notifications, enforce idempotency, retrieve current status, and start downstream workflows.

How does synchronization with Fivetran work?

Fivetran connectors perform asynchronous, connector-dependent synchronization using methods such as incremental extraction, change tracking, log-based replication, or cursor-based extraction. Martini can initiate supported operations, poll status, or react to selected webhooks, then publish the final outcome after distinguishing in-progress, successful, failed, paused, and disabled states.

How does Martini handle mapping, errors, retries, and duplicates?

Martini maps Fivetran resources and statuses into canonical enterprise models, validates required fields, and applies business rules before downstream updates. Workflows can use bounded retries, timeouts, pagination handling, stored checkpoints, stable connector identifiers, and processed-event keys to reduce duplicate provisioning and notifications. Schema and connector-specific behavior should be handled explicitly.