Integrations · Clay
This is not an MCP integration. You call RichAPI from Clay's HTTP API column with an x-api-key header and column references in the body, and the waterfall runs behind the cell. Clay stays the table, the scheduler and the interface; we are the data underneath. On email_finder, email_verifier and phone_finder a miss costs zero credits.
Last updated September 22, 2026
Create a RichAPI account at app.richapi.ai/signup and copy your API key.
25 free credits, no card.
In your Clay table, add a column and choose the HTTP API enrichment.
Method POST, URL https://api.richapi.ai/api/v1/email_finder.
Add two headers: x-api-key with your key, and Content-Type: application/json.
Build the JSON body with column references, so first_name, last_name and company_domain come from the row rather than being typed once.
Set a run condition so the column only fires on rows that have the inputs it needs, then run it on five rows and read the raw response before you map anything.
Add fields from the response for the value you want and for billed, so a miss is visible in the table instead of looking like an empty cell.
Copy, paste, edit the brackets, run.
Why it matters
Clay is a good product and we are not trying to replace it. What we replace is the layer under the cell: calling the waterfall directly means one credit pool, a per-call execution_log showing which providers ran, and no second markup on top of the provider's price.
Start with the concession, because it decides whether the rest of this page is relevant to you. Clay is the worksheet, and it is a good one. The table, the views, the dedupe, the scheduled reruns, the fact that a RevOps person can build something on Monday without asking an engineer for time: none of that is ours and we are not building it. If you are in Clay because of Clay, stay. What this page is about is the layer underneath the cell. There is no MCP server involved here and no native Clay app. Clay has an HTTP API enrichment column, we have an HTTP API, and that is the whole integration.
Create an account at `app.richapi.ai/signup` and copy your key. In your table, add a column and choose the HTTP API enrichment. Then: - **Method:** `POST` - **URL:** `https://api.richapi.ai/api/v1/email_finder` - **Headers:** `x-api-key: <your key>` and `Content-Type: application/json` - **Body:** JSON, with column references rather than literals: ```json { "first_name": "/First Name", "last_name": "/Last Name", "company_domain": "/Domain" } ``` Use Clay's column-reference picker to insert those rather than typing the slashes, since the reference has to bind to the actual column. Set a run condition before you run anything. A row with no domain will still fire the call, and the call still costs you a Clay credit for the attempt even when the body was never going to work. Condition the column on both inputs being present. Run it on five rows first and read the raw response. Then map fields out: the value you want, and `billed`, so a miss shows up in the table as a miss rather than as an empty cell you later mistake for a bug. the live OpenAPI at https://api.richapi.ai/api/v1/openapi.json carries the current request bodies per endpoint. The base is always `https://api.richapi.ai/api/v1/{endpoint}` with the key in an `x-api-key` header.
- [`email_finder`](/api/email-finder) — name plus domain, or a LinkedIn URL. - `email_verifier` — run it on an email column you imported, before anyone sends to it. - `phone_finder` — LinkedIn URL, or name plus company. - [`enrich_company`](/api/company-enrichment) and `enrich_profile` — both want a **LinkedIn URL**, not a domain. Point them at a domain column and you will get nothing and be charged for it. - `web_tech_stack` — domain in, stack out. Good as a filter column ahead of the expensive ones. - `people_search` — priced per result, which makes it a poor fit for a per-row column and a fine fit for a source. Chain them with run conditions rather than running everything on every row. Enrich the company, filter the table, then find emails only on what survived. Running the finder first and filtering afterwards means you paid for the rows you were about to delete, which is the most common way a Clay table gets expensive.
Running an enrichment column costs Clay credits. Calling us costs RichAPI credits. Both meters run. Our side: the published per-endpoint rate, with tiers on [/pricing](/pricing), and a [cost calculator](/tools/waterfall-cost-calculator) for a list. On `email_finder`, `email_verifier` and `phone_finder` a miss costs zero of our credits, because the waterfall soft-fails with `success: false` and `billed: false`. Every other endpoint bills on a 2xx, empty result included. Clay's side is Clay's to quote. What we will say is that a free miss on our meter is not a free miss on the table, so the run condition is doing real work for you. The argument for calling us direct instead of using a native waterfall is narrow and it is about price stacking. A built-in provider inside another tool is the provider's price plus that tool's margin. Going direct is one margin instead of two, and you see which provider answered.
On waterfall calls the response also carries `execution_log`. Map it into a column and an empty cell becomes readable. The log shows who ran and what each returned, so a miss is not the same problem as a broken call. We do not publish the provider roster, because it changes as we add and drop providers. The log is the per-call answer instead of a list on a marketing page.
No table. No views, no dedupe, no scheduling, no sharing a list with a colleague who does not write code. No prospecting UI, no sequencer, no CRM app, no intent data. Clay does those and we do not intend to compete with them. If you leave Clay for us you lose a product and gain an endpoint. That is a good trade for an engineer and a bad one for most teams. If you want the assistant version of this rather than the table version, the [MCP server](/integrations/claude) is where that lives, and scheduled runs are cheaper in [n8n](/integrations/n8n).
**Is there a native RichAPI integration in Clay?** No. HTTP API column only. There is no marketplace listing and no partnership to claim. **Can I use this to replace Clay's own waterfall?** You can replace the enrichment inside the cell. You cannot replace the table, and you should not want to. **Why is my column returning nothing but still billing?** Check the endpoint. Only `email_finder`, `email_verifier` and `phone_finder` are free on a miss. The rest bill on a 2xx, including an empty one, and `enrich_company` against a domain instead of a LinkedIn URL is the usual cause. **Can several people use one key?** Use named keys, one per person or per client, and usage attributes per key. There are no billed sub-accounts and no per-key budget caps. **Do I need a credit card?** No. 25 free credits on signup.
25 free credits, no card. Add one HTTP column, run it on five rows, and compare the result and the cost against whatever is currently filling that cell. Other ways in are on the [integrations hub](/integrations).