Integrations · Make (Make.com)
We do not publish a Make app. RichAPI runs inside Make as the built-in HTTP module: one POST, x-api-key header, JSON back. On email_finder, email_verifier and phone_finder a miss costs zero credits; every other endpoint bills on a 2xx, empty result included.
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 Make scenario add HTTP → Make a request.
There is no RichAPI module in the Make app directory to search for; the HTTP module is the integration.
Method POST, URL https://api.richapi.ai/api/v1/email_finder, header x-api-key set to your key, body type Raw / application/json.
Turn on Parse response so downstream modules get typed fields instead of a string blob.
Map first_name, last_name and domain from the trigger bundle, run once, and check the output bundle for success, billed and execution_log before you build anything on top of it.
Store the key in a Make connection or a data store, not pasted into the module — scenario blueprints get exported and shared.
Copy, paste, edit the brackets, run.
Why it matters
Make charges by operation and RichAPI charges by credit, so the cost of a scenario is two meters running at once. Routing on the billed field means the branch that found nothing does not also cost you the write, the notification and the retry.
Start with the part you came here to check. **There is no RichAPI module in the Make app directory.** You will not find us by typing "RichAPI" into the module search, and nobody at RichAPI is going to tell you otherwise on a page designed to rank for "Make.com enrichment API". What you get is the HTTP module, a base URL, and a header. A Make module is a wrapper around the same REST call, and wrappers lag: the module ships with the endpoints that existed when it was built, and the new ones land months later. The HTTP module has every endpoint in the catalog the day it goes live, including the ones we add next quarter.
Add **HTTP → Make a request** and fill in five fields: - **URL** — `https://api.richapi.ai/api/v1/email_finder`. Swap the last segment for any endpoint. - **Method** — `POST`. - **Headers** — one row: name `x-api-key`, value your key. - **Body type** — Raw, content type `application/json`. - **Parse response** — on. Leave it off and every downstream module sees one long string, which is how people end up writing a JSON-parse module they did not need. Request body, mapped from whatever your trigger produced: ```json { "first_name": "{{1.first_name}}", "last_name": "{{1.last_name}}", "company_domain": "{{1.company_domain}}" } ``` Run it once. Look at the output bundle. If `success` is `true` you have an email; if it is `false` you have a miss, and `billed` tells you whether the miss was free.
The mistake that costs money in Make is treating a 200 as a success. On the waterfall endpoints a miss is also a 200 — providers ran, nobody had the record, and you are not charged. Your scenario still continues down the happy path unless you branch on the payload. Put a **Router** after the HTTP module with two filters: - `success` equals `true` → write to the CRM, enqueue the sequence, do the expensive thing. - `success` equals `false` → log it, tag the record `enrich_failed`, move on. Without that router, a miss writes an empty email field over a good one, and the branch that should have cost nothing costs you three more Make operations plus whatever the CRM write is worth.
Make bills operations. We bill credits. Both run at the same time and neither knows about the other. | Endpoint | Cost | | --- | --- | | `email_finder` | `5 credits` | | `email_verifier` | `2 credits` | | `phone_finder` | `25 credits` | | `enrich_company` | `1 credit` | | `enrich_profile` | `1 credit` | | `people_search` | `0.1 credits per result — per-result pricing, so state the result count` | Zero-cost misses apply to `email_finder`, `email_verifier` and `phone_finder` only. Everything else — `enrich_profile`, `enrich_company`, the scrapers — bills on any 2xx, including one that comes back empty. Non-2xx never bills, anywhere. Credit rates are on [pricing](/pricing); the [waterfall cost calculator](/tools/waterfall-cost-calculator) will do the arithmetic for a list size. `phone_finder` at 25 credits inside an Iterator over 500 rows is the scenario that produces the surprised support ticket. Filter before the module, not after.
Map `execution_log` into your error-handling branch in Make and you can tell a real miss from a call worth retrying. Waterfall endpoints return it showing who ran and what each returned. We do not publish the provider roster. It changes. The log is the honest version: not a list on a marketing page, the actual record of who ran on your request.
Attach a **Break** directive to the HTTP module with a couple of retries. Rate limits and transient 5xx responses are normal in any API and neither bills you; what you do not want is a 400-row scenario dying on row 12 and re-running the first eleven when you restart it.
We are the data layer. No sending, no sequencing, no CRM app — you bring Make for that, and it is genuinely better at it than anything we would build. If you want the same calls without a scenario at all, the [Claude MCP integration](/integrations/claude) runs them from a chat window, and [n8n](/integrations/n8n) is the self-hosted equivalent of this page. The rest of the family sits under [integrations](/integrations). [Clay](/integrations/clay) users are usually here for the same reason: we are the waterfall behind the cell.
**Is there a Make app for RichAPI?** No. As of this writing we ship no Make module and no app-directory listing. HTTP module only. **Will there be one?** Not announced. Do not build a timeline around it. **Can I call it from Make's Custom Webhooks instead?** That is the wrong direction — webhooks receive. Use HTTP → Make a request to send. **Does a miss cost a Make operation?** Yes. Make charges for the call regardless; we do not charge for a waterfall miss. Two meters. **Can I reuse my key from other tools?** Yes, one key and one credit pool across REST, MCP and every scenario you build. Per-key usage attribution exists if you want to know which scenario spent what — create a separate key per scenario. **Does it work in Make's free plan?** The HTTP module is available on every Make plan, so yes, subject to their operation limits.
25 free credits, no card. Build the scenario with `email_verifier` first — it is the cheapest way to see the shape of a response before you spend anything real. See the full endpoint list under [platform](/platform), or start with [email finder](/api/email-finder).