$ man clay-wiki/http-column

The HTTP column is Clay's escape hatch. Every native integration has limitations — fixed fields, fixed pricing, fixed logic. The HTTP column lets you call any API endpoint, parse the JSON response, and use the result in your table. No credit cost beyond Clay's base charge. No dependency on Clay updating their integrations. If the API exists, you can use it. This is the column that separates Clay users from Clay engineers. Most people never touch it. The ones who do build things that aren't possible any other way.

PATTERN

This is the single most important HTTP column pattern in my entire workflow. MX records tell you what email provider a company uses. Google Workspace, Microsoft 365, Proofpoint, Mimecast — each one changes your outreach strategy. The pattern: (1) Set up an HTTP column with a GET request to a DNS lookup API (I use a lightweight MX lookup endpoint). (2) Pass the domain from your domain column. (3) Parse the MX record from the JSON response. (4) Use a formula column to classify: Google → Instantly, Microsoft → HeyReach LinkedIn, Enterprise-Security → caution. This is how I route every single contact in every campaign. It's not optional. Microsoft MX means enterprise — that's a signal. Google Workspace is standard outbound territory. The MX record dictates the channel.

PATTERN

Knowing a prospect's local timezone matters for send-time optimization. The pattern: (1) Use the company's HQ city or state from enrichment. (2) Call a timezone API via HTTP column to get their UTC offset. (3) Use this to schedule emails in their morning window (8-10am local). This is a minor optimization but it compounds. Emails sent at 9am local time get higher open rates than emails sent at 2am. The HTTP column makes this a zero-effort addition to any campaign table.

PATTERN

Any REST API can be a Clay column. Examples I've built: (1) SemRush API for pulling competitor domains — identify who a prospect competes with, use that in personalization. (2) FireCrawl API for deep site analysis — crawl a prospect's website and get clean markdown for Claygent to analyze. (3) Custom webhook endpoints that trigger Supabase inserts — when a row meets certain criteria, push it directly to my database. (4) Slack webhook for real-time alerts — when a high-priority lead enters the table, ping a Slack channel. The HTTP column supports GET, POST, PUT, and DELETE. You can pass headers, authentication tokens, and request bodies. It's a full API client inside a spreadsheet column.

PATTERN

API responses come back as JSON. You need to extract the right fields. Clay's HTTP column lets you specify a JSON path for the field you want. For nested responses: use dot notation to drill into the object. For arrays: specify the index. For complex extractions: pair the HTTP column with a formula column that cleans up the raw response. Pro tip: always test with one row first. API responses can vary — some companies return different structures for different inputs. Get the JSON path right on a sample before running on 500 rows and wasting credits on parse errors.

ANTI-PATTERN

The HTTP column has no built-in rate limiting. If you run 5,000 rows against an API that allows 100 requests per minute, you'll get blocked. Best practices: (1) Check the API's rate limits before you run. (2) Use Clay's run speed settings — slow it down for sensitive APIs. (3) Batch your runs in groups of 100-500. (4) Add error handling — if the API returns a non-200 status, have a formula column that flags it for retry. (5) Cache results when possible — if you've already looked up the MX record for google.com, don't look it up again on the next row. Dedupe domains first, run HTTP once per unique domain, then write back with a lookup column.

PRO TIP

Use the HTTP column instead of a native integration when: (1) The native integration doesn't expose the field you need. (2) The native integration costs more credits than a direct API call. (3) You need custom logic in the request (conditional headers, dynamic parameters). (4) The native integration hasn't been updated and the API has new features. (5) You're calling an API that Clay doesn't have a native integration for at all. The HTTP column is the most versatile tool in Clay. Learn it once, use it everywhere.

PRO TIP

MX record lookups are one of the highest-ROI uses of the HTTP column — but the value only materializes when you have the infrastructure to act on the routing decision. Understanding MX records, provider splits (Google Workspace vs Microsoft 365), sending limits, and domain warming is essential context. See the Email Infrastructure Guide at /knowledge/email for the complete infrastructure layer.