Custom audiences through Claude: what the connector accepts

Audience housekeeping looks made for delegation. Lists go stale, lookalikes pile up behind seeds nobody remembers building, and the exclusion audience that stops you paying to reach existing customers goes unchecked until a month looks strange.

It is also the corner of this connector where the gap between what a tool description promises and what it enforces matters most, because two of the operations are irreversible and one of them handles other people's personal data.

The upload tool takes raw customer data

Meta's guidance to advertisers is unambiguous about who does the hashing:

To create audiences, you must share your data in a hashed format to maintain privacy.

Meta, Custom Audiences, Marketing API documentation, read 31 August 2026. The same page names one permitted algorithm and says no other is supported.

The connector's uploader does not require that. Its own description says it takes either form, and describes what it does with the unhashed one:

The tool accepts EMAIL, PHONE, FN, LN, ZIP, CT, ST, COUNTRY, DOB, GEN, MADID values either pre-hashed … or raw — whichever is more convenient. The tool normalizes (lowercase/trim email, strip non-digits from phone, etc.) and … hashes raw values before they leave this server.

ads_update_custom_audience_users, tool description, read from the live schema on 31 August 2026

Read the last clause carefully: before they leave this server. The server is Meta's, not yours. The hashing is real, but the trip from your laptop to that server carries the customer records themselves. Two identifiers are never hashed at all, by design: the tool notes that external IDs and lookalike values pass through as-is.

Whether that is acceptable is a question about your privacy policy and your jurisdiction, not about the tool — a real decision most write-ups skip.

The Claude Ads Operator course covers which operations are safe to hand over and which stay manual.

The delete guardrail is advice, not a lock

Deleting a custom audience is permanent, and it has a side effect that is easy to miss: any ad set currently targeting that audience is paused as part of the deletion. The tool says so plainly, and also that a lookalike built on the audience blocks the delete until the lookalike goes first.

So there is a correct order of operations and the connector describes it. The question is where the description lives. It sits in the tool's response guidelines — the section addressed to the model reading the schema — as an instruction to look up the dependencies first, present the affected ad sets, and get confirmation.

That is guidance to a reader, not a precondition on the endpoint. Compare it with what happens on creation, where campaigns and ads come back paused because the creation tools make them that way regardless of how you asked. One behaviour holds whatever the prompt says. The other holds as long as the model follows the paragraph. That distinction decides which operations are safe to delegate at all.

Two vocabularies for the same audiences

The create tool and the list tool disagree about what the audience types are called. Creation accepts customer list, website, engagement, mobile app and lookalike. The listing tool's type filter accepts customer list, website, lookalike, engagement — then APP rather than MOBILE_APP, plus an offline-conversion type creation does not offer at all. The name you build an app audience under is not the name you filter for it by.

There is a second gap if you plan to work with audiences the way you work with campaigns. The connector's field catalogue — what you can select, filter and sort on when querying entities — contains no audience fields. custom_audience, audience_name and approximate_count all come back as unknown. The one related field is targeting: ad-set level only, read-only, neither filterable nor sortable.

So “which ad sets use this audience?” is not a query you can express against the entity tools. It is a dedicated call — the same one the delete tool tells the model to make first. The connector's surface is wider than most guides describe and less uniform than a single API would be.

How to use it without regretting it

1. Read and create; do not delete START HERE

   Listing audiences, checking status, renaming, labelling and building a lookalike from an existing seed are all recoverable. Deletion is not, and it pauses ad sets on the way out. The trade: cleanup stays manual, so stale audiences accumulate and you will eventually spend an afternoon on them.

2. Ask for the dependency list before you agree to anything

   “Which ad sets are using this?” has its own tool and returns names and IDs. Making it the first move turns an irreversible action into a reviewed one. The trade: on an audience nothing is using, you have added a round trip to learn that.

3. Settle the raw-data question before the first upload

   If sending unhashed customer records to Meta's server is not something you want to do, hash them yourself and supply digests — the tool takes them unchanged. Decide once, in writing, rather than mid-chat where the convenient path is the default. The trade: you now own a hashing step, and a row hashed wrongly matches nobody and fails silently as a low match rate.

• Treating a rejected removal as a completed one. The remove call can fail on a delivery threshold. If your confirmation came from a model summarising the reply, read the reply.
• Building a lookalike on a lookalike. The seed can be a customer list, website, engagement or app audience — not another lookalike. Common ask, does not exist.
• Assuming an audience is usable because it was created. Meta documents a separate terms-not-accepted failure, which is a property of the account rather than of the list.
• Letting cleanup run unattended. Meta already flags long-unused customer file audiences for deletion on a rolling basis, per its own documentation.

Try this tonight Ask for every custom audience on one account with its type, delivery status and creation date, then read it for two things: seeds you no longer recognise, and any exclusion audience you rely on that was last updated a long time ago. A stale exclusion list is the one that quietly costs money — it is still being applied, it just no longer contains the people you meant to exclude. Refresh that one before touching anything else; it is the only item on the page where doing nothing has an ongoing price.