Help & setup

Four families, four ways in

A card marked Unavailable is a platform this deployment has not been given app credentials for — there is nothing to connect to yet, and no setting of yours can change that.

The same four steps, whichever platform

1. Open the cardSettings → Connectors, then the group the platform belongs to. The rail on the left jumps straight to it.
2. Pick the level, and that starts the connectionRead-only or Read & write — there is no separate « connect » button; the level you click is the connection you are asking for.
3. Approve on the platformYou land on the platform's own sign-in and consent screen, where some of them also ask which accounts to cover. Cancelling there changes nothing here.
4. Back on the cardIt now names the account it connected as, and carries the level as a badge. Switching level later means going through the consent screen again — the current token is replaced only once the new one comes back.

The two levels

Read-only covers everything that does not change anything: listing, auditing, reporting, exporting, and reading configuration. It is the level to leave a connection on when in doubt — every audit in this product works at it.

Read & write adds the named operations listed under Details on that same card — creating, editing, cloning, publishing, bulk changes. It does not make the agent autonomous: every change still goes through an approval you give, and is recorded in the action log with the previous values.

Three extra switches appear on a card only once it is in read & write, because they are the writes that need a second decision:

• Deletions — Off by default. Left off, the agent can create and edit but never delete. On Tag Manager, turning it on asks Google for an additional permission, so it goes through the consent screen again.
• Job admin — dbt Cloud only, off by default. Creating or editing a job is the one write that keeps costing money after it is made, because a scheduled job then runs unattended and bills your warehouse. Triggering an existing job is confirmed every time and is not affected by this switch.
• Exports — BigQuery only, off by default. Sending a table or a query result out of BigQuery to Cloud Storage is the one write that moves your data somewhere else. Left off, everything the agent does with BigQuery stays in BigQuery; deletions, on or off, say nothing about it.

Three things can hold a level back, and each says so on the card: Read & write · Pro (write access is part of the Pro plan; your connections keep their settings and reading never stops), Writes off (disabled deployment-wide for that platform until its safety checklist has been verified against real credentials — no account setting lifts it), and Set up your project first on the Google cards.

Read-only: a guarantee, or a promise?

Worth knowing before you decide how much to lean on it, because the answer is not the same on every platform. Each card states its own answer under Details → How the limit is enforced.

App-enforced holds against anything the agent is asked to do, including by an assistant over MCP. It does not hold against a defect in this code, and the card says so rather than borrowing the stronger guarantee.

What Details tells you

Every card has a Details link, and it is the honest answer to « what did I just hand over? »:

• What this connection can do — how many operations are available in read-only and how many more read & write adds, with List all naming every one of them. Read from the same method tables the agent dispatches on, so it is what it will actually be allowed to call, not a summary of it.
• How the limit is enforced — the platform-enforced or app-enforced answer above, for this card.
• Scopes actually granted — read back from the token, not from what was requested: a platform can grant more or less than was asked.
• Accounts this grant covers — where the platform names them at connection time (TikTok does). It records what was authorised; it does not decide where a change may land, which is always the account named in the request itself.
• Connect / Change access — the consent link, or the token or credential form for the platforms that use one.

Meta (Facebook & Instagram ads)

You need a Facebook account that already has access to the ad accounts, through a Business portfolio. Nothing to create on Meta's side.

On the Meta Marketing card, pick a level and you land on Facebook Login for Business. That dialog asks which business portfolio and which ad accounts to include — tick every account you want the agent to report on, because one left out is simply invisible to it afterwards, whatever level you chose.

Read-only asks for ads_read and business_management; read & write adds ads_management. Meta issues a token of about sixty days, renewed on its own while the connection is in use — if it ever lapses, reconnect from the card and nothing else changes.

Ad-spend changes never go through the ordinary review card: the account is pinned to the one you named in your own message and the amount is stated in that account's currency before you answer. How that works.

TikTok, Snapchat, ChatGPT Ads, LinkedIn and HubSpot

Adobe Analytics

Adobe is the one non-Google platform that runs on your own credential, for the same reason the Google products do: the rate limit is metered per credential, and a single deployment-wide app would pool every customer behind one identity. You create it in the Adobe Developer Console, on a project belonging to your organisation.

Two kinds work, and the card asks you to register one before it can connect:

• OAuth Web App (recommended) — the agent acts as you through Adobe's sign-in, so every change is signed by your login. Paste the redirect URI shown in the card's Details panel into the credential on Adobe's side; it must match exactly.
• OAuth Server-to-Server — a technical account your Adobe admin adds to a product profile. No sign-in, and one rights setting chosen here.

Adobe's IMS scopes name products and profile claims, never verbs, so both levels ask for the same grant and read-only is enforced by this application.

Living with your connectors

• Connect only what you use. The What the agent can do right now panel at the top of Settings is the live summary — what it can change, what it can only read, what it cannot reach at all.
• Downgrading is one click. Clicking Read-only on a card already in read & write replaces the token with a narrower one.
• Disconnect on a card removes its credential here; Disconnect all in the summary does the lot. Revoking on the platform's own side — your Google account, Meta business settings, HubSpot connected apps — works too, and takes effect immediately.
• A platform you have not connected is reported as such. The agent never looks for a way around it. If the chat answers « not connected » or « read-only », that panel is where to fix it.

Why your own project

• Quotas are yours. Google meters API calls on the project that owns the credential. Another user's heavy day never slows yours down, and you can raise a limit yourself in the Cloud Console.
• Costs are yours to see. BigQuery queries are billed to the project that runs them — your project, your bill, no surprises.
• Control is yours. Every call shows up in your project's API dashboard, and you can cut the agent off by deleting one credential.

Which credential should I create?

A service account cannot reach Google Ads (the Ads API does not accept one), and its changes are signed by the robot rather than by you. Both come from the same project; you can switch later.

Deploying in a company

If an IT department creates the Google Cloud project for you, hand them the runbook for IT teams: how to create an Internal OAuth client inside the company's Google Workspace organisation, what it controls, and how it revokes access. It needs no account to read, and it exists as a PDF for a security review.

Getting a key

What it costs

Anthropic bills your key per token, separately for what the model reads and what it writes, and most of what the agent reads comes back from Anthropic's prompt cache at a fraction of the price. The current rates per model are on Anthropic's pricing page — they change, so we do not copy them here:

Keeping it in hand. Pick the model for the cost of being wrong, not the size of the request (Settings → Agent → Model): a smaller model is fine for reading and auditing, the strongest one is worth it for large writes. Turn on Concise replies when watching spend — output tokens are the expensive kind. Set a monthly spend limit in the Anthropic Console (Settings → Limits), and watch the token counter under each conversation.

Getting a key

What it costs, and what differs

OpenAI bills your key per token, separately for what the model reads and what it writes, and repeated prompt prefixes come back from its cache at a lower price. The current rates per model are on OpenAI's pricing page — they change, so we do not copy them here:

Two things to know. The agent's way of working — read first, preview, confirm, then write — was tuned on Claude, and GPT models are driven through the same instructions; on long multi-step jobs the two can behave differently, so compare them on your own work before settling. And the token counter under each conversation is comparable only within one model: the two providers count the same text differently.

How these connections work

Unlike the Google products, dbt Cloud, GitHub and Metabase connect with a token you create in your own account and paste into Settings → Connectors — no consent screen, nothing for anyone else to configure. The token is checked against the platform before it is saved, stored encrypted, and revocable at any time by deleting it on the platform's side.

Connecting dbt Cloud

In dbt Cloud: Account settings → API tokens → Service tokens → Create service token. For read-only work, give it the Read-Only, Metadata Only and Semantic Layer Only permission sets — together they cover the three APIs the agent uses (jobs & runs, model lineage & tests, governed metrics). Then in Settings, pick your access URL — the host in your dbt Cloud address bar, e.g. cloud.getdbt.com or abc123.us1.dbt.com — and paste the token.

Ask things like: « Why did last night's run fail? », « Which models have no tests? », « What depends on stg_orders? », « Give me revenue by month, as the semantic layer defines it. »

Connecting GitHub

On GitHub: Settings → Developer settings → Personal access tokens → Fine-grained tokens. Scope the token to the repositories you want the agent to see, with Contents and Pull requests permissions — read-only for audits, read and write for branch-and-PR work. Paste it in Settings.

dbt models are files in your git repository, so this is how the agent changes a dbt project at scale: it reads what exists (and what dbt says about it), generates the .sql/.yml files, and delivers them as a pull request on a working branch. Two guarantees are enforced server-side, in every mode: the agent never writes to a repository's default branch, and it never merges — reviewing the diff, watching CI, and pressing merge stay yours, in GitHub.

Connecting Metabase

In Metabase: Admin settings → Authentication → API keys → Create API key. The key takes the permissions of the group you create it in — put it in a view-only group and it genuinely cannot change anything, which is a stronger guarantee than anything set on this side. Then paste it in Settings together with the address you open Metabase at: Metabase Cloud (yourcompany.metabaseapp.com) or your own server (metabase.yourcompany.com) — both work.

One condition on that address: it has to resolve publicly. This app runs in the cloud, so a Metabase that only answers inside your own network is out of its reach whatever the key allows — and you are told so when you connect, rather than halfway through a task.

Ask things like: « Which dashboards has nobody opened this quarter? », « This question returns the wrong total, find out why », « Build me a dashboard of revenue by channel from the orders table ». With writing enabled it creates and edits questions, dashboards, collections and models — all of which keep a revision history in Metabase, so anything it changes can be rolled back there. It archives rather than deletes, and a real deletion waits for your approval.

One guarantee is enforced server-side, in every mode: the agent only ever reads the data behind a question. Running a query and changing a table are the same kind of call in Metabase, and only the first is allowed — anything that would write to your warehouse is refused before it leaves, including in the SQL it saves into a question.

Connecting your instance

Matomo connects with a token you create in your own Matomo account, pasted into Settings → Connectors together with the address you open Matomo at: your own server (https://analytics.example.com or https://example.com/matomo) or Matomo Cloud (https://yourorg.matomo.cloud) — both work. In Matomo: Personal → Security → Auth tokens → Create new token. The token is checked against your instance before it is saved, stored encrypted, and revocable at any time by deleting it in Matomo.

A token carries its user's rights. For read-only work, create it as a user who has view access to the sites and nothing more — then no setting on this side can turn it into a write. The address has to resolve publicly and answer over https: a Matomo that only answers inside your own network is out of reach of this app, and you are told so when you connect.

What the agent does with it

The whole reporting API of a Matomo core, across every site the token can see: visits, pages, entry and exit pages, referrers and campaigns, events, contents, transitions, goals and ecommerce, countries and devices, page performance, insights — over any period, with Matomo segments — plus the configuration itself: sites, goals, saved segments, annotations, custom dimensions, dashboards, and Matomo Tag Manager: containers, tags, triggers, variables and versions. With writing enabled the agent creates and changes those settings under your approval; publishing a Tag Manager version is two-step, like on Google Tag Manager, and deleting a site or a container, which erases all of its data, stays behind the deletions permission.

Deliberately out of reach, whatever the level: the visit log and visitor profiles (raw visits carry the IP addresses and identities of your visitors), user and access management, privacy tooling on one visitor's data, scheduled email and SMS reports, and instance administration.

Ask things like: « Compare last month's visits with the previous one, per site », « Which landing pages bounce the most on mobile? », « List every goal and its conversion rate this quarter », « Which tags fire on the checkout container, and when was it last published? ».

What to ask

Plain language, with the identifiers you have: a property id, a container (GTM-XXXXXX), a dataset, a customer id. The agent lists, audits, reports, exports (CSV, Excel, JSON), imports from Sheets and files, and — with write access — creates, edits, clones, publishes and bulk-patches.

• « List all my GA4 properties with their data streams. »
• « Audit container GTM-ABC123 and flag unused triggers. »
• « Clone the workspace of GTM-AAA into GTM-BBB, then publish. »
• « Export every custom dimension of property 123456789 to CSV. »

Reads, writes and approvals

Reads run immediately. Before any change, the agent lays out exactly what it is about to do — which resources, which fields — and waits for your explicit approval. A change across many resources arrives as a review card you tick and click (see Approvals & runs); destructive operations ask twice. Every write lands in the action log.

Read-only connections are the safe default: grant write access product by product, for the duration of a task, from Settings → Connectors, and reduce it back afterwards.

Long jobs

A large export runs in slices and resumes on its own — across messages, across sessions — until it is complete; nothing is redone and nothing is lost. Generated files are available for one hour.

Models and reply style

Settings → Agent chooses the Claude model and whether replies are standard or concise. See what it costs for how to pick.

The review card

When the agent prepares a change — create this dimension, rename that property, archive these dimensions everywhere, delete these tags, create these events, write these rows, deploy these campaigns — the change appears as a card, in the conversation and on the page. Nothing runs until you click, whether the card holds one line or a thousand: asking for a change in your own words is the request, and the click is the approval. This covers every product the agent writes to, with one deliberate exception below.

• What and where, by name. The card leads with the verb and the count (« Archive 3 796 custom dimensions »), then the account, property, container or workspace it touches — by name, with the id beside it so you can check.
• Four things to trust, or not. Where the request came from (this conversation, or which assistant); where its targets came from (a search over how many parents, how completely, how many matches); whether it can be undone; and when it stops waiting. « Not reversible » is the one thing shown in red — an archive GA4 cannot restore, a dbt run that cannot be un-run. A workspace change that stays unpublished, or a file changed on a branch, says so in green.
• Folded by place. A large request opens on the places it would touch, each with its count. Open a place to read its lines, untick what you want left out — a line, or a whole place — and approve the rest. The buttons stay in reach at the top.
• Every value, in full. Under each line, what the change would write — every field, a nested one laid out rather than squeezed into a phrase — and the whole request one click further, exactly as it will be sent. A short request shows it all at once; a long one shows it on request. Once a run is over, its record keeps the same detail: what each line sent, not only whether it went through.

The three numbers

The page opens on what needs you, and the badge in the sidebar is their sum:

• Decisions waiting — requests nobody has answered. A request you ignore expires after a day and never runs.
• Runs stuck — approved work that has stopped advancing. Nothing is lost: « Resume now » carries on from the first operation still untreated, never from the top.
• Operations to check by hand — writes interrupted mid-call, which may or may not have reached the API. They are never retried on their own; look at the resource, then decide.

While it runs, and after

Approving starts the work server-side. It carries on whether or not you stay on the page or keep the conversation open, retries what is safe to retry, and never applies anything twice. The card in the chat becomes a live progress line, and the page shows the same numbers: done, in flight, waiting to retry, refused, to check by hand.

A run under way can be stopped, from its card or from the page, after a second look that says how many operations would be left unrun. What is done stays done, and the record names the rest as never run. A stopped run is not resumed; ask for what remains again if you change your mind.

Once over, the record reads back the way it was reviewed: by place, with what was refused first and each refusal naming its property or container. The chat shows the tally in the thread, and the agent knows how a run it started ended. Finished runs can be searched and filtered by outcome, origin (chat or a connected assistant), connector and date.

Google Ads, Meta, TikTok, Snapchat and LinkedIn ask differently

Those five do not use the card, because they already ask something stricter. An ad-spend change is pinned to the one account you named in your own message — the agent may not choose it for you, even if only one is connected — and the amount is stated in the account's own currency before you answer. Nothing is created live and spending by default.

On TikTok that last point is worth saying plainly: the platform's own default is to start a new campaign running. Here it is created paused unless you ask for it to go live, and a request that changes many things at once tells you how many, by name, before you answer.

On Snapchat, an update replaces the whole object, so a change of name sent alone would also wipe the end date and the spend cap. The agent reads the object first and sends it back whole, and the plan says so. Creating an ad account, or changing which funding source pays and where invoices go, is a second decision that stays refused unless you have allowed it.

On LinkedIn, there is no way to try a change without making it, so the plan you answer is the only preview. New campaign groups are created as drafts and new campaigns and ads paused, and a daily budget is stated as what it is: a daily cap LinkedIn may exceed on a given day. If LinkedIn turns the request down and the fix would show the ads to a wider audience than the plan said, the agent asks you again instead of fixing it on its own.

A card would ask the question more visibly and check less. When the two appear in the same request, the whole request goes through the stricter of the two.

What you can rely on

• Nothing an assistant sends can decide a request in its place — only you can, from your own browser.
• What goes through is exactly what is ticked when you click, never more.
• Approving is not a guarantee: a connection that does not allow a change still refuses it, and the record says so.
• A request approved and a request finished are two different facts, and the page never confuses them.

Before you start

• It is a second identity, on purpose. Even if your own project already uses a service account, scheduled runs get one of their own. Settings shows the two side by side under “Which identity acts, and when”: your project acts when you ask, with whatever mode you gave it, reading or writing; this key acts when a schedule runs on its own, and only ever reads.
• Why not one key for both. One key would mean the unattended identity holds your write rights, and that its reads are indistinguishable from yours in Google Analytics' access reviews. Two accounts keep the guarantee at the Google side rather than in our code: this one is granted Viewer and holds no project role, so it cannot write even if something asked it to. Revoking one does not touch the other, and removing your project's credential removes this key too and pauses every schedule.
• It does not narrow what you can do. Writing from the chat still runs under your project. When a run finds something to fix it prepares an approval card, and approving it makes the change under your own access, at your click.
• Two steps may need an administrator. Creating a key can be refused by your organisation's policy, and access at the account level in Google Analytics needs an account administrator. Each step below has the request to send.
• What an auditor sees. The account appears in Google Analytics user lists and access reviews under the name you give it, and every read shows in your project's API dashboard. Name it so that its purpose is obvious.

What a schedule can watch

Anything the agent can read for you, on a cadence you choose. Two families, and they are set up differently.

• Google products — Analytics, Tag Manager, Search Console, Looker Studio, BigQuery, Sheets. These are read by the read-only service account, which is what the six steps below set up. Google Ads is the exception: it publishes no read-only scope and no robot identity, so no schedule reads it.
• Everything else you have connected — Meta, TikTok, Snapchat, LinkedIn, HubSpot, Adobe Analytics, Matomo Analytics, ChatGPT Ads, dbt Cloud, GitHub, Metabase. These are read on the connection you already made, read-only, and they need no key here: nothing to set up beyond connecting the product.

A schedule watches one product at a time. Watching Analytics and Meta is two schedules, not one. And whatever the product, a run never reads people: contacts, leads, members, owners and access lists are refused, by name, before a call is made.

What a schedule can prepare, and what it can never do

A run only reads. When what it finds calls for a change, it does not make it: it prepares an approval card and waits for you, in Approvals & runs. Approving it runs the change under your own access, with the mode and the opt-ins you gave that connection — so a run can never reach further than you can.

• It can prepare a write on any product it reads: open an issue on a repository, add a custom dimension to a property, open a workspace in a container, and more generally any write that product declares.
• It can never prepare a deletion, a publication, a change to who has access, or anything touching people. Those are refused when the schedule is composed and again before the card is filed, and no setting unlocks them.

Each card is replaced by the next run's, so one schedule never piles up a queue.

Composing one, and approving the plan

Schedules are written in the chat: say what you want watched and how often. The agent composes the plan and shows it back to you in the conversation, as a card with what it will read, where, under which identity, and what it would prepare. Nothing is scheduled until you approve it there, and you can run it once on real data first.

How often is up to you: every day, every week on a chosen weekday, every month on a chosen day, or once on a single date. A monthly watch set for the 31st runs on the last day of a shorter month rather than skipping it, and a one-off moves to your archive after its single run. Say it in your own words — “every Monday at 9”, “on the 1st of each month”, “just on 12 October” — and you can change it later from the card without rewriting the schedule.

Name the place too, not just the hour. Say “9am Paris time” and the hour is read in Paris. Name no place and the plan borrows the time zone the property or account already carries, and says on the card whose zone that is — so an hour that looks wrong is something you can see and correct before you approve anything.

Every version is approved on its own. If you change a schedule that is already running, the version in service keeps running until you approve the new one.

Afterwards, Scheduled runs is where each schedule lives: what it does, who it runs as, when it next runs, how the last run went and why if it went badly. From its card you can run it now, pause and resume it, change how often it runs along with its hour and time zone, archive or delete it, and stop or remove a single run.

Automation is part of Pro, and starts your 14-day trial the first time you use it — running one on real data included.

Setting up the Google key

The six steps below are only for Google products. If your schedules read Meta, GitHub, dbt Cloud, Metabase, Matomo or any other connected platform, there is nothing to do here.

What it is

YAAPI is also a connector: assistants that speak MCP — claude.ai, ChatGPT, Claude Code, Cursor and others — can use your YAAPI account directly, on the Google connections and quotas you already set up here. You ask questions in the assistant you use all day; YAAPI does the reading (and, if you allow it, the preparing) behind the scenes.

Connect from claude.ai or ChatGPT

1. In your assistant, add a connector / custom connector and paste the server URL: …/api/mcp
2. Your assistant opens a YAAPI screen. Sign in if needed, then choose the access level: Read-only, or Read + prepare changes.
3. Approve — and that is it. No key to copy, nothing else to configure.

Clients that cannot open a sign-in screen (some editors and command-line tools) can use a personal access token instead, from Settings → Agent. Personal tokens are always read-only.

What each level allows, product by product

Read-only covers every connection you have set up here — the assistant can look at everything, and change nothing:

• Google Analytics — accounts, properties, every setting (dimensions, key events, streams, links…), and reports.
• Tag Manager — containers, workspaces, tags, triggers, variables and versions.
• Search Console — search performance by query, page, country or device, sitemaps, and the indexing status of a URL.
• Looker Studio — your reports and data sources, and who each one is shared with. Changing that sharing is not available here: it is access management, and that stays in the app.
• BigQuery — read-only queries, with a cost cap: no request can change your data or run up your bill.
• Sheets — reading spreadsheets and ranges.
• Google Ads, Meta Ads, Snapchat Ads and ChatGPT Ads — campaign structure, audiences and reports.
• dbt Cloud, GitHub and Metabase — projects, jobs, runs and lineage; repositories and pull requests; questions, dashboards and the answers behind them.
• Matomo Analytics — sites, goals, segments and every aggregate report.

Read + prepare changes adds reversible drafting on Google Analytics and Tag Manager (tags, triggers and variables in a GTM workspace, container versions — not their publication — custom dimensions and metrics, key events, property settings), plus GitHub (working branches, commits and pull requests — never your default branch, never merging: you land the PR yourself) and dbt Cloud job configuration and Metabasecontent (questions, dashboards, collections and models, all of which keep a revision history) and Matomo Analytics settings (goals, segments, annotations, custom dimensions, sites), where those connectors are enabled for writing. Triggering a dbt run — real warehouse work on your bill — always waits for your approval, and Metabase only ever reads the data behind a question, never rewrites it. Every other product stays read-only whatever the level.

What is never possible, at any level

• Publishing a Tag Manager container — going live is a human decision. The assistant prepares the version; you publish it, here or in Tag Manager itself.
• Any write to Google Ads, Meta Ads, Snapchat Ads, ChatGPT Ads, BigQuery, Sheets, Search Console or Looker Studio — money, data, documents and what Google crawls have no draft layer to undo from.
• Changing who has access to your accounts — user and permission management is a security operation.

When YAAPI refuses an operation, that refusal is final on this connector — the decision comes back to you. If you ever see your assistant attempt the same operation through other means (your browser, another tool), tighten what it may do on those surfaces: YAAPI never asks it to work around a refusal.

Approvals over MCP

When a connected assistant asks to change anything — create, update, delete, archive, trigger a dbt run — nothing runs: the request lands on Approvals & runs, with a counter in the sidebar, and the assistant is told to wait. It reads the same way as a request from the chat — see Approvals & runs — and the assistant can follow the outcome with check_pending_action, but nothing it sends can decide it.

Scheduling from a connected assistant

A connected assistant can also propose a scheduled run, with propose_schedule: say what you want watched and how often, and it composes the plan and answers with a link. It schedules nothing by itself — you open Scheduled runs, read the plan, run it once on real data if you like, and activate it there. Pausing, retiming and deleting are yours on that page too; no assistant can do any of it.

Complete lists, or none

An assistant reads through a budget: a result too large for it is reduced before it sees it. Every result now says, in two separate fields, whether every page was fetched and whether everything fetched is visible — so a reduced list can never pass for a complete one, and an assistant that reads the flags never concludes that something is absent from a list it only saw part of.

For a search across many properties, containers or workspaces, the assistant can ask YAAPI to filter server-side: the whole data is scanned here, only the matches travel, and the result carries a receipt proving every parent was covered end to end. A deletion or archive spanning more than one parent must cite such a receipt: it is refused without one, when the receipt is incomplete, or when a target is not among the matches. On Approvals & runs the request then shows its provenance — parents covered, matches found, matches targeted — before you approve.

Managing and revoking

Settings → Agent lists every assistant you have approved, with its access level, and revokes one in a click. Revoking a personal token cuts off every client using it at once.

When something fails, whose is it?

Three different things can fail, and they are not fixed in the same place. Every error in the chat now starts by naming which one it is, so you never have to guess whether the problem is yours.

• The model's provider. Anthropic or OpenAI, depending on the key you configured. Their servers can be saturated or down; you will read that the trouble is theirs, that nothing ran and nothing was charged. Send the message again in a moment. Their live status is public: status.anthropic.com and status.openai.com.
• Your own account, at the provider or at Google. A key that was revoked or mistyped, a rate limit reached, an empty credit balance, an API not enabled in your Google Cloud project, a quota exhausted there. Only you can fix these, and the message says where. The model key is yours and so is its invoice: YAAPI never bills you for the model.
• YAAPI itself. Anything else. If an error names neither the provider nor your account, it is ours. It is recorded with its exact wording and its request identifier, which is what a support thread needs.

A request that failed before running changed nothing in your accounts. A bulk change that was approved and interrupted is a different matter, and Approvals & runs says exactly how far it got, including the operations nobody can vouch for.

redirect_uri_mismatch on Google's page

The redirect URI on your OAuth client does not match the one shown in Settings. Copy it again from there — Google compares every character, including the scheme and the absence of a trailing slash. Changes on the client can take a few minutes to apply.

« Google hasn't verified this app »

Expected for an External app you did not submit for verification. Click Advanced, then Go to … (unsafe). It is your own app on your own project; nobody else can use it.

« Access blocked: … has not completed the Google verification process »

Your External app is still in Testing and your account is not in its test users — or it is, and the token expired after seven days. Publish the app (step 3) rather than adding test users.

An API « has not been used in project … before or it is disabled »

That API is not enabled in your project. Open the API library (step 2), enable it, and retry a minute later.

« Anthropic is having trouble » / « Overloaded »

The model's provider is saturated or down. Nothing ran, nothing was charged and your key is fine — send the message again in a moment. It is not something to fix on your side, and it is not YAAPI: their status page says when it is over.

The chat says a product is « not connected » or « read-only »

Open Settings → Connectors: the panel at the top says what the agent can reach. Connect the product, or switch it to Read & write from its card — the change applies to the next message.

The agent keeps asking you to reconnect a product every week

The consent screen is in Testing. Publish it; then reconnect the product once.

RESOURCE_EXHAUSTED or « quota exceeded »

Your project's own quota for that API, which no other user shares. Tag Manager's is the tightest. Raise it from APIs & Services → Quotas in your project, or let the agent pace itself — it backs off and retries on its own.

Google Ads: « developer token » errors

The Ads API needs a developer token in addition to your consent, and that token belongs to this deployment, not to your project. If the Ads card says « not available here », the operator has not configured one.

« Invalid API key » or « credit balance too low » from the chat

The Anthropic key in Settings → Agent was revoked, or your Anthropic balance is empty. Check console.anthropic.com → Billing, then paste a fresh key if needed.

Replies are slow or cut short

A large model on a large job takes time; the token counter under the chat keeps moving while it works. Cut short usually means an Anthropic rate limit on a new account — limits rise automatically with usage, or on request in the Console.

• Connect products read-only first; grant write access to one product at a time, when a task needs it.
• A service account should carry least privilege: never roles/owner or roles/editor at project level. Rotate its key every 90 days.
• One project and one Anthropic key per person or per team. Do not share a client secret or a key between people: revoking it for one revokes it for all.
• Set a monthly spend limit on your Anthropic account before letting the agent run long jobs.
• If a secret leaks (chat, screenshot, log): revoke it in the Cloud Console or the Anthropic Console immediately, then save the replacement in Settings.
• Removing the credential from Settings disconnects every product at once. Deleting the OAuth client or the key in the Cloud Console does the same from Google's side.

What happens to your data

• We do not use prompts, conversations, or files to train models.
• Your client secret, service account key, Anthropic key and the tokens you grant are used only to call Google and Anthropic on your behalf, and are encrypted at rest.
• Logs are minimized and retained only for a limited operational period.
• We do not use marketing cookies.

Details on the Privacy page; the rules on the Terms of use.

Remove the agent's access to Google

Settings → Connectors → Your Google Cloud project → Remove disconnects every product at once; Disconnect on a card removes one. Deleting the OAuth client or the key in your Cloud Console, or revoking the app from your Google account, does the same from Google's side.

Export everything held about you

Settings → Data & privacy → Export my data: one JSON file with conversations, logs and usage. Secrets are left out on purpose.

Delete your account

Settings → Account → Delete my account. Immediate and permanent: conversations, logs, credentials, everything.

Get help

support@yaapi.net. Include the message the agent or Settings showed you, never a secret.