Agent skill · product strategy · jeremylongshore
clay-architecture-variants
Choose and implement Clay integration architecture for different scales
Why this skill is useful
Provides specific architectural patterns and implementation details for Clay integrations that the AI wouldn't reliably generate on its own.
What it needs
Requires clay account access. About 4k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
Clay Architecture Variants Overview Three proven architecture patterns for Clay data enrichment at different scales. Clay is a hosted SaaS -- your architecture decisions focus on how you send data in (webhooks), how you get enriched data out (HTTP API columns, CRM sync, or CSV export), and how you orchestrate the flow. Prerequisites Clay account with appropriate plan tier Clear understanding of data volume and latency requirements Infrastructure for chosen architecture tier (if queue-based or event-driven) Instructions Architecture 1: Direct Integration (Simple) Best for: Small teams, < 1K enrichments/day, ad-hoc usage. Pros: Zero infrastructure, 5-minute setup, works on all Clay plans. Cons: No retry logic, no programmatic access to enriched data, manual export only. --- Architecture 2: Webhook-in, HTTP API-out (Standard) Best for: Growing teams, 1K-10K enrichments/day, CRM integration. Pros: Full automation, programmatic access to enriched data, flexible routing. Cons: Requires Growth plan (HTTP API columns), needs public HTTPS endpoint. --- Architecture 3: Queue-Based Pipeline (Scale) Best for: Enterprise, 10K+ enrichments/day, multiple data sources. Pros: Handles any volume, automatic retries, DLQ for failures, multi-source. Cons: Requires queue infrastructure (Redis), more complex to operate. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/clay-architecture-variants