Luca P.

Hi there! 👋

Thanks so much for flagging this - I totally understand the frustration. You're right that after adding a new API key, you currently need to refresh the page before it becomes accessible in your workflow. And if you've already started building out a column, having to exit and start over is definitely not ideal.

Quick workaround for now: When you know you'll need to add a new API key, try to add it before you start setting up the column. That way you can refresh once and then proceed without interruption.

That said, this is absolutely valuable feedback for our product team. The flow should be smoother - ideally the API key would be immediately available without needing a refresh or forcing you to exit your current work. I'll make sure this gets passed along to help improve the experience.

Really appreciate you taking the time to share this! Let me know if you run into anything else or if there's anything else I can help with. 🙂

Hi Thuy, thanks for reaching out to support!

Clay does have a Webflow integration that includes a "Get collection item" enrichment action. This action retrieves items from your Webflow collections using inputs like Site, Collection, Name, or Slug.

However, I don't see specific documentation about multi-reference field support in our current Webflow integration docs. The integration can work with various Webflow field types, but I'd recommend testing it directly in your table to see how multi-reference fields are returned, or feel free to share your table with our support team so we can take a closer look at your specific use case and provide accurate guidance on whether this will work for your workflow.

Sure thing, I'll go ahead and close this ticket out, but if anything else comes up you know where to find us :)

Hey Rohail, just checking in! How did things go? Let me know if there's anything else I can do here to assist. :)

Hey Beau! Thanks for the update and for working through this with the team.

You're absolutely right - the hourly interval is currently the shortest timeframe for scheduled column runs. It sounds like you've found a solid workaround given the constraints! Running the Salesforce lookup on a schedule should give your LeanData flows plenty of time to complete the account owner updates.

I know it's not as immediate as a 20-minute delay would be, but the hourly schedule should at least ensure accuracy. If the timing becomes critical for your workflow, you could also explore using webhooks to trigger the lookup after LeanData completes, though that would require some additional setup on your end.

Thanks for the feedback on the delay feature - it's definitely something we're tracking as a feature request. Let me know if you run into any issues with the scheduled approach or if there's anything else I can help with! 🙌

Great follow-up questions! You're raising some valid UX concerns:

1) The perpetual loader issue: Unfortunately, the current UI doesn't always provide clear feedback when a custom MCP server fails to connect. The system does validate connections behind the scenes, but error messages don't always surface clearly to the user. If you're experiencing this, the best approach is to double-check that your MCP server URL is accessible and that the API key (if required) is correct.

2) Testing if MCPs are connected and working: The most reliable way to verify your custom MCP setup is working correctly is to actually use it in Claygent:

If the MCP wasn't connected properly, you'll see an error when Claygent tries to execute. This is definitely not ideal UX, and I'd encourage you to share this feedback with the Clay team—better connection validation and testing UI would benefit everyone using custom MCPs!

Hi! I took a look into the error you're seeing, and the issue isn’t coming from Clay — it’s coming from Prospeo’s side. When Clay sends the request to Prospeo’s API, their Cloudflare security firewall is blocking the traffic before it reaches the actual Prospeo endpoint. This results in the “403 Forbidden” page you’re seeing.

To resolve this, Prospeo will need to update their Cloudflare settings to allow requests coming from Clay’s servers. If you reach out to Prospeo support, you can share the following details to help them identify the block:

Once Prospeo whitelists our IP (or adjusts their WAF rules), your enrichment will run normally. Let us know if you'd like us to confirm the fix on our end — happy to help!

Hi! I took a look into the error you're seeing, and the issue isn’t coming from Clay — it’s coming from Prospeo’s side. When Clay sends the request to Prospeo’s API, their Cloudflare security firewall is blocking the traffic before it reaches the actual Prospeo endpoint. This results in the “403 Forbidden” page you’re seeing.

To resolve this, Prospeo will need to update their Cloudflare settings to allow requests coming from Clay’s servers. If you reach out to Prospeo support, you can share the following details to help them identify the block:

Once Prospeo whitelists our IP (or adjusts their WAF rules), your enrichment will run normally. Let us know if you'd like us to confirm the fix on our end — happy to help!

Talha - Do you mind sending the link (url) to the table so we can take a look?

Hi there, thanks for reaching out to support! I can see how the current docs might not cover all the details you need. Here's what's happening behind the scenes: When you add a custom MCP server in Claygent, the system supports both Streamable HTTP and SSE (Server-Sent Events) transport types, and the "MCP API key" field is actually optional—if you provide one, Claygent automatically sends it as a Bearer token in the Authorization header (format: Authorization: Bearer {your-api-key}). This means even if your MCP server uses a different auth method (like a custom header or query parameter), you'll need to configure your server to accept the Bearer token format that Claygent sends. If your MCP server requires different authentication arguments or headers beyond a simple Bearer token, you may need to wrap it with a proxy that translates Claygent's authentication into what your server expects. The system doesn't currently expose additional configuration options for custom auth methods or transport-specific arguments in the UI, so the Bearer token approach is the standard path forward. If you need more specific help setting up your particular MCP server, feel free to share more details about which server you're trying to connect and what auth method it uses!