Integrations · TexAu
TexAu is the no-code product you click; RichAPI is the data API you call. Two separate products from the same team. If you want a visual workflow builder, use TexAu. If you want endpoints, credits and an execution_log in your own code, you are already in the right place.
Last updated September 22, 2026
Decide which product you actually want.
TexAu if the person doing the work does not write code and wants a builder; RichAPI if the work lives in a script, a backend job or an agent.
For RichAPI: create an account at app.richapi.ai/signup and copy your API key.
25 free credits, no card.
Call https://api.richapi.ai/api/v1/{endpoint} with an x-api-key header.
That is the whole auth story — no OAuth, no per-workspace install.
For TexAu, sign up separately at texau.com.
It keeps its own account and its own wallet; a RichAPI key does not log you into it.
Credits do not pool across the two products.
Budget them separately. The two products keep separate wallets, so check each dashboard before you quote a combined bill.
Copy, paste, edit the brackets, run.
Why it matters
Most teams have both problems: an operator who needs a workflow they can edit without filing a ticket, and an engineer who needs the same data inside a product. Those are two products, not one with a mode switch, and pretending otherwise is how tools end up bad at both.
The short version: **TexAu is the no-code product, RichAPI is the data layer.** Same team built both. They are not the same thing wearing different branding, and RichAPI is not "the TexAu API" — that phrasing gets used casually and it is wrong in a way that costs people time, because it implies a TexAu account gets you an API key and it does not. If you landed here looking for TexAu itself: [TexAu](https://texau.com/) is the separate no-code product, with its own signup and its own wallet.
**TexAu**, if the person doing the work does not write code. A visual builder, workflows you can edit without a deploy, and a UI for the operator running list building and outreach preparation day to day. **RichAPI**, if the work lives in code. Endpoints, an `x-api-key` header, prepaid credits, and a JSON response you can put behind your own product's enrich button. No UI, no builder, no canvas — deliberately. The whole surface is `https://api.richapi.ai/api/v1/{endpoint}` and a hosted MCP server at `https://mcp.richapi.ai/mcp`. Most teams that use both split it the obvious way: whoever owns the go-to-market motion works in the builder, and whoever owns the product calls the API. Neither has to wait for the other.
- **Separate signups.** A RichAPI key does not log you into the no-code product, and an account there does not mint an API key here. - **Separate credits.** Do not plan a budget assuming one pool covers both. The two products keep separate wallets, so check each dashboard before you quote a combined bill. - **Separate pricing pages.** Ours is [pricing](/pricing). We are mid-rebrand and some older material blurs the two. When something you read elsewhere conflicts with this page about what RichAPI is, this page is the one being maintained.
A builder is faster for the first ten runs and worse for the ten-thousandth. What you get down here: **Receipts.** The `execution_log` that comes back from a waterfall endpoint holds one entry per provider attempt, with its status. You can log it, alert on it, and answer "why did this record come back empty" without opening a support ticket. **A billing rule you can reason about.** `email_finder` at 5 credits, `email_verifier` at 2, `phone_finder` at 25 — and on those three, a call where every provider ran and nobody had the record costs zero. Every other endpoint bills on a 2xx, including one that comes back empty. Non-2xx never bills, anywhere. **Your own control flow.** Retries, concurrency, dedupe, what happens on a miss: all yours, in a language you already use. The [waterfall cost calculator](/tools/waterfall-cost-calculator) will tell you what a list size costs before you run it. **Agents.** MCP means an assistant can call the same endpoints directly — see [Claude](/integrations/claude) or [LangGraph](/integrations/langgraph), and the full family under [integrations](/integrations). A visual builder cannot be driven by an agent in the same way; the API can.
Do not use RichAPI if what you want is a screen with rows in it. We have no prospecting UI, no table view, no campaign sender, no sequencer and no CRM app, and none of those are on this page's roadmap because they are somebody else's product. If your day is spent clicking through lists, the no-code product exists precisely for that and you will be happier in it. The migration path that works is to prove the sequence by hand where clicking is cheap, notice which two calls carried the result, then rebuild those two as API calls and throw the rest away. Almost every workflow reduces to a search, a finder and a verifier — which is the order in [list build and verify](/use-cases/list-build-and-verify).
**Is RichAPI the TexAu API?** No. Separate products. Your TexAu account does not carry an API key for this, and this key does not work there. **Same company?** Same team, yes. Two products, mid-rebrand. **Can I use one set of credits across both?** No. The wallets are separate; check each dashboard before you plan a combined budget. **Does the no-code product use these endpoints under the hood?** Not a question we answer on a pricing-adjacent page, and it would not change anything about what you get here. What is documented is the public API, and that is what this site describes. **Which one should a five-person team pick?** Whichever matches the person doing the work. If that person opens a terminal, it is this one. **Can I move later?** Yes, in the direction described above. There is no export/import between the two — you rebuild the two or three calls that mattered, which is usually an afternoon.
25 free credits, no card, on the API side. Run [email verifier](/api/email-verifier) against a list you already trust and compare the answers — cheapest possible way to find out whether the data layer is worth wiring in. The full endpoint surface is under [platform](/platform).