Integrations · Make (Make.com)

Make.com Enrichment API — RichAPI via HTTP Module

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.

In short: RichAPI does not publish a native Make (Make.com) app or module. Integration with Make is done through Make's built-in HTTP module ('Make a request'), calling the RichAPI REST API at https://api.richapi.ai/api/v1/{endpoint} with the API key in an x-api-key header, POST method, JSON body, and 'Parse response' enabled so fields are typed for downstream modules. Commonly used endpoints are email_finder, email_verifier, phone_finder, enrich_company, enrich_profile, people_search and web_tech_stack. On the waterfall endpoints email_finder, email_verifier and phone_finder, a call where sources ran but found nothing returns HTTP 2xx with success false and billed false, and costs zero credits. All other endpoints bill on any 2xx response, including a response with an empty result. Non-2xx responses never bill on any endpoint. Billing is prepaid credits from a single pool shared with MCP and direct REST use. New accounts get 100 free credits with no credit card. RichAPI is a data API only: it has no prospecting UI, no CRM app and no email sending.

Last updated November 4, 2026

Connect it

  1. 1. Create a RichAPI account at app.richapi.ai/signup and copy your API key.

    100 free credits, no card.

  2. 2. 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.

  3. 3. Method POST, URL https://api.richapi.ai/api/v1/email_finder, header x-api-key set to your key, body type Raw / application/json.

  4. 4. Turn on Parse response so downstream modules get typed fields instead of a string blob.

  5. 5. 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.

  6. 6. Store the key in a Make connection or a data store, not pasted into the module — scenario blueprints get exported and shared.

Make (Make.com)

What you can ask for

Webhook from a form →
Webhook from a form → email_finder → Router: verified email goes to the CRM branch, miss goes to a Slack branch.
Google Sheets Search Rows →
Google Sheets Search Rows → Iterator → enrich_company → update the row with headcount and industry.
Scheduled scenario: pull yesterday's signups,
Scheduled scenario: pull yesterday's signups, run email_verifier, filter on the invalid result and tag them for manual review.
Airtable trigger → phone_finder →
Airtable trigger → phone_finder → only write the number back when success is true, so misses never overwrite a good record.
HTTP module in a loop
HTTP module in a loop with Break error handling, so one 5xx does not kill a 400-row scenario 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.

Make.com enrichment: the HTTP module is the integration

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.

The one module you need

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:

{
  "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.

Routing on the result, not the status code

The mistake that costs money in Make is treating a 200 as a success. On the waterfall endpoints a miss is also a 200 — sources 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.

Credits, and the second meter

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; the 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.

The receipt on Make

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 source 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.

Error handling worth adding

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.

Where we stop with Make

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 runs them from a chat window, and n8n is the self-hosted equivalent of this page. The rest of the family sits under integrations. Clay users are usually here for the same reason: we are the waterfall behind the cell.

Make FAQ

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.

Start with Make

100 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, or start with email finder.

FAQ

Frequently asked questions

No — Make.com Enrichment API — RichAPI via HTTP Module authenticates through the connection you set up, using the same key and credit pool as the REST API. Revoking access from your RichAPI dashboard disconnects it immediately.
No — MCP and REST share the same credit pool and the same published endpoint rates. There's no separate MCP surcharge.

More from RichAPI

More companies

Browse company profiles with company overviews, key details, and email formats.

Start free with 100 credits

Get 100 free credits to explore RichAPI with no card required.

Free tools

Use our Email Permutator, llms.txt Generator, Waterfall Calculator, and live API demo — all free to try.

Related integrations