Clay’s HTTP API column type lets you call any REST endpoint directly from a table row, using values from other columns as inputs. Here’s the exact configuration for a RocketVerifier verification column.
Step 1: Add an HTTP API column
In your Clay table, click + Add Column → Enrich → HTTP API.
Step 2: Configure the request
| Field | Value |
|---|---|
| Method | POST |
| URL | https://api.rocketverifier.com/v1/verify |
| Headers | Authorization: Bearer YOUR_API_KEY, Content-Type: application/json |
| Body | {"email": "{{Email}}"} — map {{Email}} to whatever column in your table holds the lead’s email address |
Step 3: Map the response fields to new columns
The response is nested under data, so use Clay’s path-extraction (click the field picker after a test run) to pull out:
data.status→ new column “Verification Status”data.score→ new column “Verification Score”data.domain.disposable→ new column “Is Disposable”data.domain.acceptAll→ new column “Is Catch-All”
Step 4: Filter before export
Once the column has run across your table, add a Clay filter view: Verification Status = deliverable OR (Verification Status = risky AND Verification Score > 70) — a reasonable default send-safe threshold — before exporting or pushing the table to your outreach tool.
Testing with a small batch first
Run the HTTP API column against a handful of rows first (Clay lets you preview a single row’s result before running across the full table) to confirm the field mapping and your chosen status/score threshold look right, before running the enrichment across a large list and spending credits on the whole table.
A note on Clay-specific rate limits
Clay’s HTTP API columns respect whatever rate limits the underlying API enforces — if you’re verifying a very large table, running in smaller batches (filter to 500-1,000 rows at a time) avoids hitting RocketVerifier’s per-minute rate limit on your plan tier.