Skip to main content
Docs
Feature Requests Onboarding Trust Center Status Page

Community

Twitter

Not planned
Irwan Dharmawan User

Fivetran Feature Request: Twitter/X Organic Connector — Support for Regular (Non-Ads) Accounts via X API v2

Request Type: Connector Improvement
Connector: Twitter Organic
Submitted by: FRnD OS Brand Insight
Date: April 2026

Title

Connector Improvement: Support X (Twitter) Organic Data Sync for Regular Accounts Using X API v2 (Without Requiring an Ads Account)

Summary

The current Fivetran Twitter Organic connector requires users to have an active Twitter Ads account with ACCOUNT_ADMIN, AD_MANAGER, or CAMPAIGN_ANALYST permissions and at least one campaign with a promotable user. This is because the connector is built on top of the Twitter Ads API, which gates access behind an Ads account — even for organic (non-paid) tweet data.

We are requesting Fivetran to build or extend the Twitter Organic connector to support regular X accounts (non-Ads) by leveraging the X API v2 standard endpoints, which are now available under X's pay-per-use pricing model and do not require an Ads account.

Problem Statement

Many brands, creators, and small-to-medium businesses use X (Twitter) purely for organic content — they do not run paid ads and do not have an Ads account. Under the current connector design, these users are completely locked out of syncing their organic tweet data through Fivetran.

This creates a significant gap for platforms like ours (FRnD OS Brand Insight), which allow end-users to connect their own X accounts via OAuth for content performance analytics. Our users are primarily Indonesian brands and SMBs who publish organic content and want to track metrics like impressions, views, engagements, likes, reposts, and follower growth — but many do not have or need an Ads account.

The current workaround (creating a free Ads account with no spend) adds unnecessary friction, confuses non-technical users, and creates compliance overhead since X's Ads API application requires a separate approval process with a stated advertising use case that may not reflect organic-only analytics.

Proposed Solution

Build a new authentication mode or connector variant for the Twitter Organic connector that uses the X API v2 standard endpoints with OAuth 2.0 (PKCE) authentication, enabling regular X accounts to sync organic data without an Ads account.

X API v2 Endpoints That Support This

Data Needed X API v2 Endpoint Notes
User's own tweets GET /2/users/{id}/tweets With tweet.fields expansions for metrics
Tweet public metrics tweet.fields=public_metrics impressions, likes, reposts, replies, quotes, bookmarks
Tweet non-public metrics tweet.fields=non_public_metrics,organic_metrics Requires user-context auth (OAuth 2.0 PKCE) — available for the tweet author's own tweets
User profile data GET /2/users/{id} user.fields=public_metrics for followers_count, following_count, tweet_count, listed_count
Media metadata expansions=attachments.media_keys media type, dimensions, duration, preview URL
Hashtags & mentions tweet.fields=entities hashtags, mentions, URLs, cashtags extracted from tweet text

Key insight: The organic_metrics and non_public_metrics fields on the tweets endpoint provide the same impression and engagement data that the Ads API provides — but only for the authenticated user's own tweets. This is exactly the data the current Twitter Organic connector syncs, but accessed through the standard API instead.

Suggested Schema Mapping

The new connector mode should produce tables compatible with (or identical to) the existing Twitter Organic schema to maintain compatibility with Fivetran's dbt twitter_organic transformation package:

Existing Table X API v2 Source Mapping
tweet /2/users/{id}/tweets Map public_metrics + organic_metrics → favorite_count, retweet_count, followers (at tweet time via user lookup), full_text, created_at, etc.
tweet_media expansions=attachments.media_keys Map media.type, media.url, media.height, media.width
tweet_hashtag tweet.fields=entities Extract entities.hashtags[].tag
tweet_symbols tweet.fields=entities Extract entities.cashtags[].tag
tweet_user_mention tweet.fields=entities Extract entities.mentions[].username
twitter_user_history /2/users/{id} Snapshot public_metrics per sync for follower trend tracking
account_history /2/users/{id} Map name, username, description, location, verified

Tables that are Ads-specific (card_history, scheduled_tweet_history, card_component) can be left empty or excluded when syncing via the standard API mode.

Authentication Flow

Aspect Current (Ads API) Proposed (X API v2)
Auth method OAuth 1.0a with consumer keys OAuth 2.0 with PKCE
Account requirement Active Ads account + campaign + promotable user Any regular X account
API approval Ads API application required Standard developer account only
Permission scope ACCOUNT_ADMIN / AD_MANAGER / CAMPAIGN_ANALYST tweet.read, users.read, offline.access
Pricing Included in Ads API access X API v2 pay-per-use credits

Business Case

  1. Massive untapped market. The vast majority of X accounts are regular accounts without Ads access. Supporting them opens up Fivetran's Twitter Organic connector to millions of potential users — creators, SMBs, agencies managing non-advertising clients, and analytics platforms like ours.

  2. X's own API evolution supports this. Since February 2026, X has moved to a pay-per-use model with no subscription tiers required. The organic_metrics and non_public_metrics fields are available to any authenticated user for their own tweets. The technical barrier that originally justified the Ads API dependency no longer exists.

  3. Competitive gap. Competitors like Supermetrics, Airbyte, and social media tools like Metricool already support regular X account connections for organic analytics. Fivetran's current Ads-only requirement is a disadvantage in the market.

  4. Platform partner use case (FRnD OS Brand Insight). We are building a multi-tenant analytics platform where brands connect their own X accounts via OAuth. Requiring each brand to create an Ads account before they can use our Fivetran-powered pipeline creates unacceptable onboarding friction and significantly reduces conversion rates. A standard API mode would eliminate this barrier entirely.

  5. Compatibility with existing dbt models. If the new connector mode maps to the same schema, existing Fivetran users can switch or add standard API connections without rebuilding their transformation layer. The fivetran/twitter_organic dbt package would work seamlessly.

Estimated API Usage (Per Connected Account)

Operation Estimated Calls/Month Notes
Fetch user tweets (paginated) 100–500 Depends on posting frequency
Fetch user profile 30–60 Daily or twice-daily snapshots
Total reads per account ~200–600 Well within standard rate limits
For 100 connected accounts ~20,000–60,000 Manageable under pay-per-use

Implementation Suggestions

  1. Add an "Authorization Mode" toggle in the Fivetran connector setup: "X Ads API (requires Ads account)" vs. "X API v2 (standard account)". This mirrors how the Twitter Ads connector already supports "Standard OAuth 1" vs. "Custom API credentials."

  2. For X API v2 mode: use Fivetran's Connect Card with OAuth 2.0 PKCE redirect flow. The user logs in with their regular X account, grants tweet.read + users.read + offline.access scopes, and Fivetran stores the refresh token for ongoing syncs.

  3. Graceful degradation: Some fields available via the Ads API (e.g., card data, scheduled tweets) won't be available via the standard API. These tables should sync as empty or be excluded, with clear documentation noting the difference.

  4. Rate limit handling: X API v2 has per-endpoint rate limits (e.g., 900 requests/15 min for user tweet timeline). Fivetran's existing retry and backoff logic should handle this, but the connector should respect the x-rate-limit-remaining headers.

Additional Context

Summary

We're asking Fivetran to add an X API v2 authentication mode to the Twitter Organic connector so that regular X accounts (without an Ads account) can sync their organic tweet performance data. The X API v2 now provides the same organic metrics that the Ads API does for an account's own tweets. This would unlock Fivetran's Twitter Organic connector for the majority of X users who don't run paid campaigns, and enable analytics platforms like FRnD OS Brand Insight to offer Fivetran-powered pipelines without requiring each end-user to create an unnecessary Ads account.

We are happy to participate in a beta program, provide test accounts, or join a consultation call to support development of this feature.

Please sign in to leave a comment.

Comments

1 comment

Date Votes
  • Official comment
    Lucas Alexander Fivetranner

    Hi Irwan,

    Luke from the Product team here. Thanks for the detailed write-up.

    As you pointed out, our Twitter Organic connector is built on the X Ads API, which X provides to advertising partners at no cost. This is also how other data pipeline tools (Supermetrics, Funnel, Improvado) provide organic Twitter analytics; their "organic" connectors also require an Ads account for the same reason. Tools that use the standard X API v2 instead, like Airbyte, only sync tweet content and metadata, not engagement or impression metrics.

    The X API v2 does expose organic_metrics and non_public_metrics via user-context auth, but there are significant constraints that make it impractical for a production data pipeline:

    1. Even with the new pay-per-use model, X API v2 pricing starts at $0.005/read and scales to $5,000/month (Pro) or $42,000+/month (Enterprise) at any meaningful volume.
    2. Organic metrics are only available for tweets created within the last 30 days, limiting historical depth compared to what the Ads API provides.

    We'd need to pass these API costs through to customers, which would make the connector significantly more expensive for a narrower dataset than the Ads API already provides for free, and would require an overhaul of our current pricing model.

    We understand this creates friction for users who don't run ads. The workaround of creating a free Ads account with no spend remains the most practical path. If X changes their pricing model or makes organic metrics available through the Ads API for non-advertisers, we'd revisit this.

    Thanks for the thoughtful request, and apologies, this is not something we plan to implement. I'll revisit this decision if we see significant demand and/or changes to X's API policies. 

    Cheers,
    Luke