Ingesting Data From Multiple Meta Accounts: The Hard Part

Every guide to ingesting Meta data lands on the same three options: a no-code ETL platform if you want dashboards, a unified social API if you are building software, or the native Graph API if you have engineers to spare.

The split sounds sensible. It is also the reason a lot of teams end up building the same thing twice.

The dividing line that actually matters is not "analyst versus developer." It is the write path versus the read path.

The write path is publishing: scheduling a post, replying to a comment, sending a WhatsApp message. It is one call, one side effect, done. Unified social APIs are genuinely good at this, and if publishing is what you are building, use one.

The read path is everything else: pulling insights, post performance, comments, follower demographics and ad spend, for dozens of accounts, on a schedule, with history, and keeping it queryable. This is not an API problem wearing a data hat. It is a data problem, and a thin proxy over the Graph API does not solve it.

Nearly every "AI workflow" built on social data is a read-path workload. An agent that drafts next week's content calendar, a churn model that watches engagement decay, an internal tool that shows a client which creatives worked: none of those are asking a question about right now. They are asking a question about a trend, and trends live in stored, comparable, attributable history.

What the read path actually demands

Once you look at it as a data problem, the requirements stop being about endpoints:

1. Many accounts under one configuration. Fifty Pages and forty Instagram profiles means fifty and forty sets of tokens, permissions and pagination cursors. Adding a client should not be a code change.
2. Row-level attribution. Every record must carry the account or page it came from, or your cross-client rollups are guesswork.
3. Backfill and history. Meta lets you reach back a limited window (two years for Instagram). Miss the window and the data is gone permanently, no retry.
4. Idempotency. Rate-limited runs get retried. Without a stable natural key you get duplicates, and duplicated engagement metrics quietly poison every model downstream.
5. Rate limits as a design constraint, not an error handler. Meta calculates limits per app, per user and per business use case. Platform limits work out to "Calls within one hour = 200 * Number of Users," while ads insights with advanced access gets "190000 + 400 * Number of Active ads" and standard access only "600 + 400 * Number of Active ads." Exceed them and you get error codes plus an estimated_time_to_regain_access in minutes.
6. Version churn as an operating cost. Each Graph API version "will remain active for at least two years from its release." That is a rolling refactor on someone's calendar, forever.
7. Governance before delivery, not after. Comment text and audience data carry personal data. If PII only gets stripped after it lands in your store, it has already landed in your store.

A unified API can help with 1 and 5. Items 2, 3, 4, 6 and 7 are storage, schema and pipeline concerns. You will build them yourself, or you will use something that already has them.

Where Dataddo sits

Dataddo is an ELT platform, and that description usually makes builders assume it belongs in the dashboard column. That assumption is out of date. The pieces that matter for the read path are the pieces Dataddo runs as product:

Multi-Account Extraction. One source configuration applied across every account, so each row states which account it came from via account name/ID or page name/ID as columns. It covers the Facebook connectors (Ads, Graph, Leads, Page, Post, Video), Instagram, TikTok, LinkedIn Ads and organic, Snapchat, YouTube Analytics, X, plus Google Analytics 4 and Google Ads for the paid side. One flow can combine up to 100 sources.

Depth per platform, not lowest common denominator. Unified APIs normalize to a shared schema, which means the interesting fields get dropped. Instagram Organic alone exposes 27 datasets, including Reel and Story lifetime insights, media comments, follower and reached-audience demographics by age, gender and country, and the hourly distribution of online followers. A normalized "post object" cannot represent that.

Idempotency built in. dataddo_hash is a fingerprint over each record's key fields, designed as a natural key for upserts. dataddo_extraction_timestamp records when each row was pulled, which is what you need to track how a metric changed over time. These are the two columns you would otherwise write yourself, badly, twice.

Schema drift absorbed, not escalated to you. Item 6 on the list above is the one that never shows up in a build estimate. Platforms add fields, rename them, and retire whole metrics, and each Graph API version is only guaranteed for two years. Dataddo handles those source-side schema changes, so a renamed field is our maintenance work rather than your on-call page. This is the difference between a connector you rent and an integration you own: the ownership version keeps sending you bills in the form of Tuesday-morning incidents.

Push as well as pull. Not everything worth ingesting is available on a polling schedule. Where a platform pushes events rather than serving history, Dataddo can take a webhook rather than forcing you to stand up and operate a receiver of your own. On the way out, data can also be published to event systems: Apache Kafka and Azure Event Hubs are documented targets, with the partition key set to your entity identifier when consumers need per-entity ordering.

Governance before the data leaves. Hash Sensitive Fields replaces selected personal-data columns with a hash before the data leaves Dataddo, so raw values never reach your store. On the delivery side there is PII exclusion, deterministic column hashing, and a Data Quality Firewall where, in blocking mode, records that fail the rules never land in the table.

A headless API, so there is no UI in your product's way. The Headless API creates authorizers, sources, destinations and flows programmatically, and supports white-label OAuth for your end customers. That last part is the one product teams care about: your users connect their own Facebook Page inside your app, under your brand, and you never handle a Meta token. The default quota is 10,000 calls per day across all endpoints, with X-RateLimit-* headers on responses.

Retrieval that fits an agent. Data can land in BigQuery, Snowflake, Databricks, S3 or Azure Blob Storage, or you can skip the warehouse entirely: SmartCache holds the latest extracted data with no storage layer to operate, retrievable over REST as JSON or CSV, or as Apache Arrow. There is also an MCP endpoint at https://headless.dataddo.com/mcp over Streamable HTTP, so an agent queries the data directly instead of you writing a retrieval tool for it.

A way to answer "which metric do I even want?" This is the underrated one. The hardest part of a first Meta integration is rarely the HTTP call. It is working out that reach, impressions and views are three different things, that they mean different things on Reels than on feed posts, and which of them your question actually needs. A unified API answers that by removing the question: it picks a normalized shape for you, and you take what it gives. Dataddo's MCP endpoint answers it the other way, by exposing dataset and field descriptions as semantic grounding, so you (or an agent, or an LLM in your editor) can explore what each platform genuinely offers and then select it. Same friction removed, opposite trade: normalization buys speed by discarding platform depth, discovery keeps the depth and shortens the learning curve instead. If your product's value is in the specifics of platform data, you want the second one.

That is the shape of the read path: connector maintenance, account fan-out, keys, history, governance, discovery and retrieval, all as infrastructure you configure rather than code you own.

This is not theoretical

The two public reference points worth knowing, because they map to the two halves of this post.

Scale of account fan-out. One of the world's largest beauty and consumer goods companies runs 65,000+ social accounts through Dataddo across Facebook, Instagram, YouTube and TikTok, into BigQuery, deployed inside their own GCP tenant. The stated problem was exactly item 1 on the list above: connecting to 65,000 individual brand accounts, each requiring its own OAuth authorization, each potentially added or removed at any time, across dozens of markets. What was built for them is an automated governance layer over roughly 1,200 active authorizers that picks up new accounts and cleans up removed ones with no human in the loop. If you are sizing a build against "dozens of accounts," note the ceiling is three orders of magnitude higher than that.

Embedded in someone else's product. Publicis Groupe Brasil uses the headless API to put integration functionality inside their own data product, including the ability for their clients to authorize connections to their services directly through Publicis Groupe's own user interface. Their numbers: 3 FTEs of pipeline maintenance avoided, and as they put it, "direct access to Dataddo's headless API streamlined new product features that would have taken 2+ months to develop in-house." That is the white-label OAuth path in production, in an agency data product, which is the closest public analogue to "I am building software on social data."

What Dataddo does not do

Being clear about this is more useful than pretending otherwise.

• It does not publish. No scheduling posts, no replying to comments, no outbound messages. Dataddo reads. If you need to write to a platform, you still need a publishing API or the native ones.
• There is no WhatsApp Business connector in the catalog today. Connectors get built on request, typically in about four weeks, so if WhatsApp Business data is a requirement, ask rather than assuming the answer is no. Conversational data does need a push model rather than a schedule, which is what the webhook path above is for.
• It does not beat the platform's own limits. Nothing does. Meta's rate limits set the practical floor on freshness for social sources, whatever sits in front of them.

The revised recommendation

• Reporting and dashboards: an ELT platform into a warehouse or BI tool. This was never in dispute.
• Building software or AI workflows: the same ELT platform, consumed headlessly. You want the account fan-out, the keys, the history and the governance, and you want it reachable over an API or MCP rather than through a UI. A unified API gives you a proxy; this gives you a data layer.
• Publishing and outbound: a unified social API or the native ones. Different job, different tool.
• WhatsApp and conversational data: a webhook, not a schedule. Either point the Cloud API at your own receiver, or push it into your ingestion layer and keep one place to govern.
• Native APIs only: viable when social data is your core product and the integration is your moat. Otherwise you have volunteered for a permanent maintenance rotation against a platform that ships breaking versions on a two-year clock.

The uncomfortable part for anyone mid-build: the unified API decision usually gets made in week one, when the requirement reads "we need Instagram data." It starts hurting in month six, when the requirement has become "compare this client's Reel performance to the same period last year across all their accounts." That second sentence is a warehouse question, and it arrives for almost everyone.

If you are building on social data and want to see the read path handled for you, browse the Headless API docs or talk to us about your architecture.