| name | clay-architecture-variants |
| description | Choose and implement Clay integration architecture for different scales and use cases.
Use when designing new Clay integrations, comparing direct vs queue-based vs event-driven,
or planning architecture for Clay-powered data operations.
Trigger with phrases like "clay architecture", "clay blueprint",
"how to structure clay", "clay integration design", "clay event-driven".
|
| allowed-tools | Read, Write, Edit, Grep |
| version | 1.14.0 |
| license | MIT |
| author | Jeremy Longshore <jeremy@intentsolutions.io> |
| tags | ["saas","clay","migration","scaling"] |
| compatibility | Designed for Claude Code, also compatible with Codex and OpenClaw |
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.
┌──────────────┐ webhook ┌───────────┐
│ Your App │───────POST─────>│ Clay Table │
│ (or CSV) │ │ (enriches) │
└──────────────┘ └─────┬─────┘
│
CRM action
or CSV export
│
v
┌───────────┐
│ CRM / DB │
└───────────┘
async function directEnrich(leads: Lead[]): Promise<void> {
for (const lead of leads) {
await fetch(process.env.CLAY_WEBHOOK_URL!, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(lead),
});
await new Promise( (r, ));
}
.();
}