It’s not an “OR” between those filters. What’s happening is that the two filters operate on different underlying signals, so when you combine them you’re not strictly narrowing the same dataset the way “industry + country” does.
Products/Services = keyword match in descriptions and product text (so “saas” only catches companies that explicitly use that term).
AI Industry filter = classification based on what the company does (often derived from the website), so it can include software/IT companies that never say “saas” in their text.
When you apply the AI filter, you’re effectively broadening coverage to “companies the model believes are software/IT,” which can increase results even if your keyword filter stays the same. If you want a true “AND” behavior for “SaaS + Software/IT,” the most reliable approach is to keep Products/Services as your hard constraint (or use a more specific keyword set) and treat the AI industry filter as an expansion tool rather than a narrowing filter.
On the display name note: I can’t change Mitch’s name directly, but I’ll pass the feedback along internally so it’s clearer in community threads.
Hey - Thanks for this! We're always looking to make the product better and this feedback is super helpful for us. We're going to pass this over to our product team so they can better evaluate things and see if/where this might fit into the roadmap as a future improvement.
Claygent can reliably fetch and read publicly accessible PDFs.
What’s working best today in Clay at scale:
Use Claygent or Navigator to discover the canonical PDF URL, then run a second Claygent step focused only on fetching and extracting text from that exact URL, with retries and strict instructions to ignore secondary pages.
Gate downstream actions with a confidence or provenance check so only high-confidence parses continue, which helps with cost control at 10k to 20k accounts.
There’s no fully Clay-native way yet to guarantee OCR or bypass gated viewers, so the hybrid approach you described is exactly what advanced teams are doing today. This is the right channel for it, and you’re not missing a simpler built-in option right now.
Hi,
Thanks for clarifying. The data wasn’t deleted, but the column was likely overwritten when you added data from another table. When a column is remapped or rerun from a source table, Clay will replace the existing values with newly found data if auto-update is enabled. If auto-update is off, this overwrite wouldn’t occur.
If you can share which table and column this happened in, I’m happy to take a look and suggest ways to prevent this going forward. I can also check whether there’s anything we can do to recover or reattach the original data.
Hey - Thanks for this! We're always looking to make the product better and this feedback is super helpful for us. We're going to pass this over to our product team so they can better evaluate things and see if/where this might fit into the roadmap as a future improvement.
Hi,
Thanks for sharing all the details and table links. I understand the urgency and the credit impact here.
What you’re seeing isn’t specific to your setup or this client’s table. LinkedIn frequently blocks automated access at the profile level, and when that happens the AI will consistently return errors like “Unable to access LinkedIn info.” This can vary by profile set, which is why the same column may work for other clients but fail repeatedly for this one. Rebuilding the column or duplicating the table won’t change that behavior, and continued retries will keep consuming credits.
To avoid further credit burn, the recommended approach is to stop relying on live LinkedIn access in this column and switch to a supported enrichment path, such as Enrich Person from Profile, which pulls structured data without scraping LinkedIn pages directly. That’s the only reliable way to get consistent results here
Our team is checking in general what they can do to fix this tho nothing as of yet.
If you have a row number and a table feel free to send it and we'll flag it again (like last time) but this isn't something that is a bug per se and that's why we have other tools to help with this.
Our team is checking this
Hi Luke,
“Previous version of the true/false field” means those rows were created when the checkbox/boolean column was stored in an older format.
Lookup isn’t an upsert or a live sync. It won’t automatically refresh in the People table when something changes in the Company table. To pick up the corrected value, you have to rerun the lookup (or rewrite the row) so it fetches the latest value again.
You can set them to run on a schedule as well
Hey Augustin,
Thanks for sharing the table and the screenshot.
What you’re running into here isn’t a Clay tier limitation. The error is coming directly from OpenAI, and it means the API key you’re using has exceeded its quota or billing limit, not its request rate.
A couple of important clarifications:
• Being on Tier 5 in Clay doesn’t override or increase limits on your OpenAI account.
• Each OpenAI API key has its own usage caps based on:
• Available prepaid credits or billing balance
• Monthly spend limits set in OpenAI
• Organization-level quota
• When that quota is exhausted, OpenAI returns this exact error, even if Clay is functioning normally.
How to fix this:
1. Go to your OpenAI dashboard and check Usage and Billing for the key augustin-gpt-3-key.
2. Make sure:
• Billing is active
• You still have available credits
• Your monthly spend limit hasn’t been hit
3. If needed, add credits or increase the limit, then re-run the rows in Clay.
Once OpenAI lifts the quota block, the table will run without any changes needed on the Clay side.
Let me know if you have more questions.
Hey Alexander,
Right now the built-in Exa integration in Clay is limited to that “perform a search” action (the /search endpoint you’re seeing in the HTTP template). It doesn’t expose the “clean list of phone numbers” feature you’re seeing inside Exa’s UI, so you won’t be able to pull phone numbers from Exa through that prebuilt action as-is.
Here are the two paths forward:
If Exa has a phone-specific API endpoint
You can still do this in Clay, but it would need to be a custom HTTP API enrichment that hits Exa’s phone/contacts endpoint (not /search).
If you can point me to the Exa API docs for the phone feature (or the endpoint name), I can help you format the request and map the response.
If that phone feature is UI-only (no public API)
Then Exa won’t be the right source inside Clay for phone numbers.
In that case, you’ll want to use Clay’s phone number enrichments/providers instead (so the output is actually a phone field, not just search results).
Let me know if you have more questions.
Hey,
I took a look at the table you shared.
I went ahead and issued a refund for the credits used here. This was a one-time adjustment to account for what happened in this table. Going forward, we won’t be able to apply additional refunds for similar cases.
Everything else in the setup looks fine now, so you shouldn’t see further unexpected credit usage from this table.
Let me know if you have more questions.
