Enrich email addresses by API with an AI
Have an assistant run the email finder across a whole file, including the retry that recovers addresses almost nobody thinks to try.
Finding an address through the API takes two calls: you submit the search, you fetch the result. The real value of handing this to an assistant lies elsewhere: in the retry logic on failures, in the handling of credits, and in writing results as you go rather than at the end.
The file to hand your assistant
It covers the three Emelia enrichment tools, with their exact routes, what the public documentation gets wrong, and the full loop for processing a file of contacts.
Find an email address, verify an address, find a phone number. The three tools, the shared asynchronous pattern, and how to process a file without wasting credits.
- The routes of the three tools and their shared pattern: you submit, you get an id back, you poll
- The field the public documentation calls optional while the server requires it
- How to actually test whether a search succeeded, and why it is not the field you would expect
- The retry on contacts that were not found, with the full loop in pseudocode
- How credits work, and why the balance drops then climbs back during a run
- What is structurally impossible to find, and the failure rate at which you should change channel
The retry almost nobody does
An address search starts from two pieces of information: the person's full name and their company. For the company you send its name, which is required, and with it its domain name, which gives the best results on average.
And here is what few people do: when the search finds nothing with the domain, make the call again without the domain, leaving only the company name. The second attempt regularly succeeds where the first one failed, because the domain of the public website is not always the one that carries the mail.
This is exactly the kind of logic you cannot impose in an interface, because it would double everyone's calls. But an assistant that has the rule in its reference file applies it on its own, only on the contacts that were not found, so at no extra cost on the rest.
The credit is deducted the moment the search goes out, then returned when the search ends with no result. A second attempt on a contact that was not found therefore only costs you a credit if it succeeds, except in the rare case where it times out with no answer from the provider. That is the one case where re-running a search is a good idea.
What an assistant does better than a bulk file run
File based enrichment exists in the Emelia interface and is enough in most cases. Going through the API with an assistant becomes worthwhile on three specific points.
- It chains attempts based on what it finds, instead of applying the same call to everyone.
- It writes as it goes. A run of a thousand contacts takes more than an hour: a file written line by line can be resumed where it stopped, whereas a run that keeps everything in memory loses the credits already spent.
- It carries straight on to the next stage without you handling a file at all: create the contact list, load the contacts it found into it, set the ones it did not find aside in a second file, and build the campaign.
The rules not to let it forget
- Never run an address found by the email finder back through the verifier. It is already checked before it reaches you. You would pay twice, and a stricter check sometimes rejects a perfectly good address.
- A generic address is not a contact. If the file already contains
contact@, do not count it as found: in outreach it is worth next to nothing, and it often lands in a mailbox nobody ever reads. - A 50% discovery rate is normal, with a range of 30 to 70% depending on the industry. On freelancers or independent professionals, 20% is already good: that is not a reason to stack up more tools, it is a reason to change channel.
Frequently asked questions
The questions we get asked on this topic, answered briefly.
Does the enrichment API use the same credits as the interface?
Yes, it is the same counter: 1 credit for an address found, 0.25 for a verification, 50 for a phone number. The credit is deducted when the search starts and returned if it finds nothing, so on balance you only pay for data that is delivered.
Why does my credit balance drop during a run and then climb back?
That is the refund for contacts that were not found, which lands at the end of each search. It is not a bug, and an assistant watching the balance mid-run should not be alarmed by it or stop the run.
Can you run a thousand searches in parallel?
No. Each search queries mail servers in real time, and the submission itself waits for the provider's answer: beyond five to ten concurrent searches, you will not go any faster.
Do you have to provide the country?
Yes, and it is the most common trap: the public documentation presents it as optional while the server rejects the call without it. Always send a two letter country code, FR by default for France.