Four beta integrations. Every other status, named.

Meta Ads

Why it is here. The account Mako audits, watches daily, and can be authorised to adjust.

Permissions we request:

Where the connection runs through Facebook Login for Business, our authorize request omits the permission list entirely and the granted set comes from a configuration inside our Meta app rather than from our code. Meta's own consent screen shows you the permission set you are actually granting, and that screen is the authority.

What we read

• Which ad accounts your login can reach: account id, name, currency, account status, the business that owns it, and lifetime amount spent
• Account summary: name, currency, status, lifetime amount spent, business name and timezone
• Campaigns: id, name, status, effective status, objective, daily budget, lifetime budget and start time
• Performance at account, campaign, ad set and ad level: spend, impressions, clicks, CTR, CPC, CPM, frequency, reach, purchase ROAS, actions, action values and cost per action
• The same figures broken out by day, which is the history the daily watch compares against
• Ads and creative: name, status, effective status, and the creative's id, name, thumbnail URL, image URL and Instagram permalink
• The state of a campaign or ad set immediately before a change, and again immediately after, to verify it

What can change, after you approve it

• Pause or activate a campaign.
• Set a campaign daily budget. Campaign-level budgets only, so a campaign whose budget lives on its ad sets is refused, and so is one on a lifetime budget.
• Move daily budget between two campaigns, or between two ad sets, inside one account, with the total held constant.

What we never touch: Creating or deleting campaigns, ad sets or ads. Uploading creative. Targeting, bidding, schedules and objectives. Lifetime budgets. Account settings. The Conversions API and your pixel. Pages, posts and audiences.

Guardrails, enforced in code

• A budget increase over 300%, which is more than four times the current figure, is blocked before an approval card is ever created
• A budget change over 20% in either direction shows a warning above the approve button, because it can restart Meta's learning
• A rebalance across two different accounts is blocked and fails closed
• A rebalance cannot take the source down to zero. Pausing is a separate, explicit action
• A campaign covered by a lock rule you wrote cannot be paused, and the refusal quotes your rule back to you

Where this stands today. Meta reads and guarded write code exist, but Meta's app review is still in progress. New grants are limited to Meta reviewers and explicitly allowlisted supervised test accounts. Meta is not part of the ordinary beta offer, and its implemented write tools are not a general availability claim.

Google Ads

Why it is here. Search, where the money leaks one query at a time.

Permissions we request:

Google publishes one Ads permission and it covers reading and writing. There is no read-only version to ask for, so read-only is a behaviour we enforce rather than a permission we request: the write switch on your connection starts off, and while it is off the change tools are not sent to the model.

Google can carry forward scopes you granted to the same OAuth client in an earlier consent. We store the set Google reports back rather than the set we asked for, so our own record never understates what a stored credential can do. Search Console is closed and its scope is not requested by the product.

What we read

• The accounts your login can reach, with name, currency and status
• Campaigns: id, name, status, channel type, exact budget id and name, daily or total period and amount, and sharing state
• One exact campaign budget with its complete linked-campaign set, up to 100 campaigns; a larger set is refused rather than called complete
• Campaign performance: cost, impressions, clicks, conversions and conversion value, plus the same series by day
• Active Google Ads experiments: exact experiment and arm identities, traffic split, treatment and control metrics, and Google-supplied point estimates, margins of error and p-values. Missing performance stays unknown, and no winner is selected automatically
• Ad groups: id, name, status and the campaign they belong to
• Keywords: text, match type, status, cost, clicks, impressions and conversions
• Search terms: the term, the keyword that matched it, cost, clicks and conversions
• Responsive search ads: headlines, descriptions, final URLs and policy approval status
• Existing campaign and ad-group asset relationships, plus bounded asset content needed to review an exact proposed link change
• Complete product-group trees for one Performance Max asset group or Standard Shopping ad group, up to 200 nodes, including inclusion state and eligible direct CPC bids
• The negative keywords already on a campaign, so a proposal does not duplicate one
• Campaign and budget state before and after a change, to verify it

Reads stop after 5 pages, and at between 50 and 200 rows depending on the report. When a read is cut short we label it truncated rather than presenting a partial list as the whole account.

What can change, after you approve it

• Supervised rollout, off by default: pause 2–10 exact currently enabled campaigns in one account. The user must name every campaign by exact ID or full name. One approval shows the complete set and always requires a second confirmation. Google validates and receives one all-or-nothing request with partial success disabled; every campaign is re-read afterward. Bulk enable, budget, targeting and mixed-operation batches are not implemented, and restoring campaigns requires separate reviewed approvals.
• Supervised rollout, off by default: end one exact currently running Google Ads experiment. The approval binds the complete experiment, arm, traffic-split and attached-campaign state, requires a second confirmation, validates with Google, checks for drift twice and sends one non-retried end request. Treatment delivery stops immediately; treatment settings are not promoted, no winner is chosen and Sable Mako provides no one-click undo. Experiment creation, scheduling, promotion and graduation are not implemented.
• Pause or enable a campaign.
• Permanently remove one exact already-paused campaign. The campaign and its budget identity are bound to the card, checked before and after Google validation, removed once and re-read. An uncertain response is never replayed, and Google cannot restore the campaign ID, history or learning state.
• Create and attach one operational label, attach one existing label or remove one label relationship from one exact campaign, ad group, ad or positive keyword. This metadata-only family is off by default and re-reads the target and complete attached-label list before an atomic write.
• Supervised rollout, off by default: attach, pause, enable or remove one existing asset relationship on one exact campaign or ad group. Supported links are sitelinks, callouts, structured snippets, calls, lead forms, prices, promotions, apps, images and hotel callouts, plus applicable campaign-level Business Name and Logo links. The target, asset content and current relationship are re-read before Google validates and receives one request. Account-level links other than the separate callout-creation family, location asset sets, asset creation beyond the separate callout, call and lead-form families, asset editing, and Performance Max asset-group assets are excluded. Production provider acceptance is still pending.
• Supervised rollout, off by default: change the name, enabled or paused status, HTTPS destinations or display paths of one existing Performance Max asset group. The exact campaign, daily budget, currency, asset group and current settings are bound to the card and checked twice around Google validation before one update. Creative assets, asset links, audience signals, product groups, URL expansion, campaign budget and bidding remain unchanged by this operation. Saved settings are re-read immediately; serving and policy status can change later.
• Supervised rollout, off by default: add or remove one search-theme or existing-audience signal on one exact Performance Max asset group. The complete signal set and exact campaign, account and asset group are bound to the card and checked twice around Google validation before one mutation. Signals guide Google’s optimization; they do not restrict targeting or delivery to the named theme or audience. Audience creation, Customer Match uploads, creative, product groups, URL expansion, campaign budget and bidding remain unchanged by this operation.
• Supervised rollout, off by default: include or exclude one existing non-root leaf in a complete Performance Max or Standard Shopping product-group tree, or change one existing included Manual CPC Shopping leaf’s direct bid. The card binds the whole tree, account, campaign, container, currency and exact leaf. Google validates; the tree is re-read for drift before one atomic request and again to verify the result. Trees over 200 nodes, roots, subdivisions, shared-budget Shopping campaigns, arbitrary tree construction and Merchant Center item creation are refused. Production provider acceptance is still pending.
• Rename one existing campaign. The approval binds its exact current name and status, refuses drift, and re-reads the result. Delivery, budget and targeting are unchanged.
• Supervised rollout, off by default. Turn Search Partners on or off for one existing Search campaign with a confirmed daily budget, after an explicit request and exact approval. Enabling a shared-budget campaign is refused. Google Search itself, Display, budget and bidding settings are unchanged.
• Change exact campaign dates or tracking settings, with a separate release gate off by default. Dates and tracking are separate approval cards. Account-local whole days only, no shared-budget date changes, bounded tracking fields and ValueTrack macros. Verification checks saved settings, not click paths or analytics results.
• Change one exact campaign targeting or delivery control behind a separate release gate off by default: country, named region, radius or language targets; demographic exclusions; device bid modifiers; the complete account-time-zone schedule; or placement exclusions. Country and language operations use up to 10 reviewed codes. Regions resolve through Google from an exact name and country code or an exact geo target id, and radii bind coordinates, distance and units. Shared-budget campaigns and removal of the last positive location or language are refused. Audience links use the separate ad-group family.
• Set or clear one exact target CPA or target ROAS, or switch one eligible campaign between standard Maximize Conversions and Maximize Conversion Value, behind a separate release gate off by default. A strategy switch also binds the complete conversion-goal map and enabled primary actions. Shared portfolio strategies, shared budgets, unsupported campaign types, drafts and experiments are refused. The exact strategy, target, currency and budget are bound to the card; Google validates and re-reads the result.
• Set or clear one exact target CPA or target ROAS on an existing eligible portfolio strategy, behind the same default-off release gate. The card binds the strategy and every linked campaign, counts shared budgets once and shows the combined daily ceiling. Google validates, checks the whole set again, sends once and re-reads the result. A fresh approval is required to restore the prior target.
• Set a non-shared campaign daily budget. A shared budget is refused in this path because changing it would move money in campaigns the card does not name.
• Supervised rollout, off by default: change one existing shared daily budget’s amount or name, or one eligible campaign total budget. The card binds the exact budget, currency and complete linked-campaign set. Google validates, the state is checked again, one budget field is sent, and the budget plus every linked campaign are re-read. It never creates, assigns, unassigns, unshares or removes a budget. Portfolio-strategy-aligned budgets and experiments are refused. Undo needs another approval and cannot recover spend or learning effects.
• Supervised rollout, off by default: permanently dismiss one exact Google-native recommendation after a separate approval. The card binds Google’s current recommendation ID, type, affected resources and impact estimate; the suggestion is re-read before one non-retried dismissal and afterward for verification. Dismissal does not alter campaign delivery and Google provides no undo. Applying a suggestion is never delegated to Google’s generic apply endpoint: any supported campaign change must use its own Sable Mako approval family.
• Supervised rollout, off by default: include or exclude one exact category-and-origin conversion goal for one campaign, or restore that campaign to the account’s current defaults. The complete goal map and backing conversion actions are checked twice. Custom goals, experiments, incomplete reads and a result with no enabled primary bidding signal are refused. This goal tool does not create or edit conversion actions, tags, attribution or account-wide defaults. Every approval requires a second confirmation.
• Supervised rollout, off by default: create one exact secondary website page-load, website-click, mobile click-to-call or website-call conversion action. The conversion owner and complete current inventory are bound and checked twice. Google validates before the approval is stored and again before one non-retried creation. The verified receipt returns Google’s code but does not claim it is installed or firing. Editing or removing actions, making one primary, changing goals or attribution and altering account defaults are not supported here.
• Supervised rollout, off by default: create one exact 1–25-character advertiser-authored callout and link it at account level. The complete bounded account-callout inventory is checked twice, Google validates the exact atomic request, and a second confirmation is required before one non-retried creation. The receipt verifies the exact marked asset and account link. Google may still review or limit it, and this tool cannot edit or delete the underlying asset.
• Supervised rollout, off by default: create one exact call asset for a named Search campaign after Google validates its eligibility. The card binds the country code, phone number, account-level reporting choice and complete business hours in the account time zone. A second confirmation is required before one non-retried creation. The new immutable asset is verified and remains detached; attaching it needs a separate approval. Replacing a number creates a new asset and leaves the old one unchanged.
• Supervised rollout, off by default: create one exact Google-hosted lead form for a named Search or Performance Max campaign after Google validates its eligibility. The card binds every visible sentence, requested field, HTTPS privacy policy, post-submit destination and four advertiser policy attestations. A second confirmation is required before one non-retried creation. The verified form remains detached; attaching it needs a separate approval. Leads stay available through Google-hosted download and are not delivered to or stored by Sable Mako.
• Create a new campaign, paused, with its budget, targeting, ad groups, keywords, copy and images in one card. Released in Production for admitted workspaces. Approval creates the campaign PAUSED, so it spends nothing until you approve activation separately.
• Add between 1 and 20 negative keywords to a campaign, as exact, phrase or broad, defaulting to exact. Every term shows on the card with its match type before you approve.
• Remove between 1 and 20 existing campaign negative keywords. Exact text, match type and Google's live criterion id are checked again before the write.
• Add, pause, enable or remove between 1 and 20 positive keywords in one ad group. Existing criteria are bound to Google's live ids, and every result is re-read after execution.
• Pause, enable or rename one existing ad group. The approval binds its exact live name and status, refuses drift, enforces caps when enabling, and re-reads the result.
• Supervised rollout, off by default: create or remove one paused Search ad group, change its Manual CPC bid, or add, exclude, remove or change the mode of one exact existing user-list audience link. Exact approval, Google validation and result verification are required. Removal is permanent. Audience creation, Customer Match uploads and Google’s wider audience taxonomy are not supported.
• Supervised rollout, off by default: change one Search campaign between presence-only and presence-or-interest targeting. Exact approval, locks, caps, validation and verification are required. Countries, languages and exclusions stay unchanged.
• Supervised rollout, off by default: create one paused responsive search ad in an existing standard Search ad group after reviewing all copy and destinations. One exact validation-and-create run passed in an isolated Preview; the family is not active in Production. Enabling requires another approval.
• Supervised rollout, off by default: change one keyword’s Manual CPC bid or HTTPS destinations, or replace its match type. Exact approval, current locks and caps, Google validation and result verification are required. Match-type replacement creates the new criterion and removes the old one atomically, refuses criteria with labels or customizers, and cannot preserve the old criterion id or learning state.
• Pause or enable one exact existing ad. The approval binds the ad, its ad group and its campaign, refuses drift, enforces caps when enabling, and re-reads the result. This status operation leaves content unchanged.
• Supervised rollout, off by default: permanently remove one exact already-paused ad. The ad and both parents are bound to the card and rechecked before the one removal request. The same ad id and learning state cannot be restored; interrupted responses are reconciled by reading and never by replaying the removal.
• Replace the complete reviewed headlines, descriptions, pins, HTTPS final URLs and display paths of one paused responsive search ad, behind a separate release gate off by default. Google validates, the exact ad and parent state are checked again, and content is re-read. The ad stays paused and may re-enter policy review.

What we never touch: Image, video or non-responsive-search creative, and content changes to enabled ads. Arbitrary Shopping tree creation or rebuilding, and bidding strategy types. Deleting campaigns or enabled ads. Conversion action settings. Budget sharing. Billing.

Guardrails, enforced in code

• The same 300% block and 20% warning as Meta
• A shared budget is blocked in the single-campaign budget path. The separate shared-budget family is off by default, names every affected campaign and checks them again before one field is sent
• A change has to resolve to exactly one connected Google account. If it is ambiguous, Mako stops and asks
• There is no budget rebalance on Google Ads, and the agent is instructed to say so rather than fake one with two separate writes

Where this stands today. Google Ads is the controlled-beta integration. Its deterministic catalog contains twenty-one rules; twelve apply to ecommerce workspaces and twelve to service workspaces. The connector and audit have Production read evidence. Campaign status, campaign name and one private daily-budget path have supervised Production write-and-inverse evidence. Every action family remains separately gated by workspace, and Settings shows which families, if any, are released. Exact approval remains mandatory; the other families still need provider acceptance before release.

Google Merchant Center

Why it is here. The product feed behind Shopping, where a bad title costs every impression.

Permissions we request:

Google publishes one Merchant Center permission and it covers reading and writing, the same as Ads. There is no read-only version to ask for, so read-only is a behaviour we enforce rather than a permission we request: publishing starts off on your connection, and while it is off no publish tool is sent to the model and the server refuses a publish even if one were proposed.

What we read

• The Merchant Center accounts your login can reach, with their names
• The data sources in an account, so we adopt an existing feed rather than creating a second
• Products already in the account, with their offer ids and attributes
• Item-level issues and per-country approval status, which is what the feed audit reports
• The same product list again after a publish, to confirm what was accepted

Product reads stop after 5 pages of 250. When a read is cut short we label it truncated rather than presenting a partial catalog as the whole account.

What can change, after you approve it

• Publish the built feed. The first publish makes Sable Mako the PRIMARY data source for that Merchant Center account, which replaces whatever feed supplies your Shopping ads today, and the card says so before you approve. Only products that changed since the last publish are sent. Nothing is published if the build has an error Google would reject.

What we never touch: Bids, budgets or campaigns. Your Merchant Center account settings. Shipping, tax or returns configuration. Deleting a data source. Anything in an account you did not connect.

Guardrails, enforced in code

• Publishing is off by default on the connection, and arming it takes a confirmation
• A first publish also requires typing the word PUBLISH, because it replaces the feed serving your ads
• The feed is rebuilt and revalidated at the moment you approve, so a card drafted against an older catalog cannot publish a feed nobody reviewed
• A build with any error Google would reject cannot be published at all
• Merchant Center accepts items one at a time, so a publish reports each item's outcome and can end partial rather than claiming success

Where this stands today. The connector, reads, catalog import, feed audit, rules and preview are implemented and open to the controlled beta. Publishing stays off until the write switch is armed and the exact publish is approved, and remains under supervised validation until publish, verify and recovery have a complete production evidence pack. If Google refuses to list your accounts at connect time, the screen says so and names it as ours to fix. Implemented code is not a customer-available publishing promise.

TikTok Ads

Why it is here. The hole in a blended number, for a store whose third channel we cannot see.

Permissions we request: There is no permission string in our code to print here. TikTok fixes an app's permission set when it approves the app in its own developer portal, so our authorize request sends no scope parameter at all. That makes this the one row on the page where the honest answer is a name from somebody else's dashboard rather than a literal from ours.

The set was read-only until 2026-08-18, when TikTok approved a second application covering campaign, ad group and ad management, audiences, creative, catalogs, pixels and measurement. We deliberately left out TikTok Shop and GMV Max, which are a campaign type this product does not use, and Automated Rules, because nothing here ever writes without your approval and holding a permission for unattended changes would contradict that. TikTok's own consent screen shows you the set you are actually granting before you approve it, and that screen is the authority, the same way Meta's is. TikTok reports the granted set back to us as numeric ids and we store what it reports rather than what we asked for. It publishes no map from those numbers to permission names, which is why the check in front of every TikTok write still does not recognise the grant and still refuses.

What we read

• Which advertiser accounts your login can reach: advertiser id and name
• Account details: name, currency, timezone and account status. That is a second call, because the account list carries none of them
• Daily performance for the account: spend, impressions, clicks, conversions and TikTok's own attributed purchase value
• The same figures per campaign, with the campaign id and campaign name, day by day

A day TikTok sends no row for is stored as unread rather than as a zero. TikTok filters days with no data out of the response entirely, so a day with no spend and a day we never read arrive looking identical, and writing zeros there would understate spend and inflate every ratio built on it. A window TikTok answers as partially successful is stored incomplete rather than whole. The purchase value above is what TikTok attributed to its own ads: there is no attribution-window parameter on the reporting endpoint, each ad group carries its own windows, so those figures are not comparable with Meta's and are never labelled revenue.

What can change, after you approve it

• Create a new campaign, ad group and ad in one card, every object paused. Off for every account today, and held off by three separate things: the capability switch is a constant in our source, the write switch does not accept TikTok as a provider at all, and the permission check in front of every TikTok write does not recognise the grant TikTok reports back. When on, nothing is activated by the approval: the tree is created paused and you turn it on yourself in TikTok Ads Manager. TikTok publishes no way to validate a campaign before creating it, so the card says we checked it and TikTok did not.

What we never touch: Deleting anything. Changing a campaign, ad group or ad that already exists: budgets, bids, targeting, schedules and statuses. Uploading creative: the video has to be in your account already and we send its id. Audiences, pixels and the Events API.

Where this stands today. TikTok approved the developer app and the read code is implemented, but no sanitized production read evidence pack is complete. New grants are restricted to allowlisted supervised tests. Campaign creation is switched off, numeric write-scope mapping still fails closed, and no TikTok write is offered. No audit check reads TikTok yet; the eleven Meta checks and Google’s twenty-one-rule catalog are separate engines.

Shopify

Why it is here. Your revenue and returns are what turn a ROAS number into a profit judgement.

Permissions we request:

All five are read permissions. read_inventory reads a variant's unit cost, so a product's margin can inform its Shopping feed; the other four cover sales and catalog. We deliberately do not request read_all_orders, the protected permission that would let us list orders older than 60 days, because the reporting gain does not justify the access. Shopify shows you the permission list on its own install screen before you approve it, and a store that granted a wider set at some earlier install keeps that grant: what bounds the reads is the code, and no Shopify customer, line item or fulfilment endpoint is called anywhere in it.

What we read

• Shop settings: name, domain, currency, plan and timezone
• Daily sales from Shopify's own analytics: gross sales, discounts, returns, net sales, total sales and order count
• Product count
• Order count for a window, and a revenue total summed from the orders themselves
• Cancelled order count for a window

The revenue total for a window is a sample and the sample size travels with the figure. Orders are read 100 rows at a time and we follow Shopify's cursor rather than stopping at the first page, up to a budget of 50 pages. Past that the window comes back marked incomplete instead of being passed off as the whole total. When Shopify counts orders and returns none of them, revenue comes back empty with the reason in plain language, never as zero. A day holding an order whose money we cannot read is removed whole and named, from the live total and the stored series alike, so the two never disagree about what a day was worth.

What can change: Shopify is read-only today. It is absent from the list of providers the write switch accepts, so the switch refuses to arm for it, no proposal tool exists, and the code that executes approved changes has no Shopify branch. The only request we send to Shopify that is not a read is the install handshake itself.

What we never touch: Customer names, emails and addresses. Line items. Fulfilment and shipping. Discount codes. No customer, line-item or fulfilment endpoint is called anywhere in our code.

Where this stands today. Your gross margin sets the ROAS a campaign has to clear. Once there are enough measurable returns, that bar is raised by your own return rate rather than by an industry figure. Blended MER joins live Meta spend to Shopify revenue in one number, and it excludes Google Ads spend, which the number says on its face. New installs are closed while Shopify's own app review completes; a store already installed keeps syncing every night.

Google Analytics 4

Why it is here. What the site itself recorded, checked against what an ad platform claims for the same traffic.

Permissions we request:

Read-only by definition. This permission cannot change anything in your property, and Google shows it to you on its own consent screen before you approve.

What we read

• Your GA4 account summaries and the property list under them, so you can pick a property
• Sessions, total users, engaged sessions, key events, ecommerce purchases, purchase revenue and total revenue, by traffic source and medium, day by day
• The same window rolled up by channel group: paid social, paid search, organic search, direct, email and referral

These are the site's own numbers, not an ad platform's attributed figures, and they will not match what Meta or Google Ads reports for the same traffic. That difference is the reason to read both, not an error in either one. A property GA4 reports no currency for comes back with its revenue named as an unknown unit rather than assumed to be dollars.

What can change: Nothing. There is no write permission and no write path.

What we never touch: Audiences, custom dimensions, user-level or demographic breakdowns, and real-time reports. The seven metrics listed above are the whole set we request, and no audience, demographic or real-time endpoint is called anywhere in our code.

Where this stands today. The connector, nightly sync and two live read tools are implemented, Google approved analytics.readonly, and GA4 is open to the controlled beta. Production evidence is pending: no sanitized connect-and-read pack is complete yet. No audit check reads GA4 and no write path exists.

Google Search Console

Why it is here. What people searched to find your site, and the pages they landed on, read nightly and live in chat.

Permissions we request:

This is the read-only variant. It cannot add a site or submit a sitemap even if we wanted it to. Google classes it as non-sensitive, so it needed no verification.

What we read

• The list of your verified sites, so you can pick one
• Search queries and the pages they landed on, with clicks and impressions, day by day

What can change: Nothing. There is no write permission and no write path.

What we never touch: Sitemaps, URL inspection, indexing coverage, mobile usability, Core Web Vitals and rich-result status. Only search queries and pages are read.

Where this stands today. The connector, the two spine tables, the nightly sync and two live agent read tools are built and shipped, and Search Console is open to the controlled beta: a connected site is read every night the same way Meta and Google Ads are, and the agent reads its search queries and pages live in chat. The button stayed closed for a week on the belief that webmasters.readonly needed Google's verification; it is a non-sensitive scope and never did. Production evidence is pending: no sanitized connect-and-read pack is complete yet.