Coming soonAutomation
Make + Kawaa
Verify emails inside your Make scenarios
A dedicated Kawaa app for Make is coming soon. It is not yet published in the Make app directory. In the meantime, you can verify emails inside any Make scenario today by calling our REST API from Make's built-in HTTP module, with all of Make's routing, filtering and error handling around it.
Kawaa app for Make coming soon
Until it is published, you can verify emails in any scenario with Make's HTTP module calling our REST API. The steps are below.
What you can build today
- Verify an address in any scenario with Make's HTTP module
- Send each result down its own route with routers and filters
- Retry or set aside failed checks with Make's error handlers
- Check lists on a schedule, or as new records arrive
Setup
How to set up
Get your Kawaa API key
The Kawaa Make app is not yet published. Until it is, copy your API key from the Kawaa dashboard to use with Make's built-in HTTP module.
Add an HTTP module
Add the HTTP app's "Make a request" module with method POST, URL https://api.kawaa.com/v1/verify, and your key in an X-Api-Key header.
Send the email as JSON
Set Body type to Raw and Content type to JSON (application/json), and map the email field from your trigger module into the request content: {"email": "<mapped email>"}. A form-encoded body is refused with a 400 ("Request body must be valid JSON").
Make a retry safe
A verification is charged when Kawaa accepts the request, so a module Make retries after a timeout or a 5xx error could be charged twice. Add an Idempotency-Key header that identifies this one verification: the same every time the module is retried, different for any other record, address, or future scheduled run, and 1 to 255 printable ASCII characters with no spaces or commas. Hash the trigger event ID (or a schedule-run ID created before the HTTP module), record ID, and address with SHA-256 using Make's sha256() function. Keep the event or run ID stable on retries, but use a new one for the next scheduled run, so the run is not answered with the earlier run's result. That run is a new request and is charged again, 0.5 credits when Kawaa reuses a result from the last 24 hours. A retry of a request Kawaa already accepted is not charged again, and a key reused for a different address is refused with a 409 before anything is charged.
Add routing logic
The POST answer's data.status is the email verdict (such as valid, invalid, or risky): route on it. Only when it is pending, GET https://api.kawaa.com/v1/jobs/ followed by its job_id with the same X-Api-Key header, and poll after a delay while the job's data.status is pending or processing. When the job's data.status is completed, route on data.results[0].status. Send a failed job, or a completed one with no result, to an error route; the job lifecycle status is not the email verdict.
Use cases
What teams do with Make and Kawaa
Complex lead scoring with email verification
Multi-channel data synchronization
Automated list cleaning schedules
E-commerce order validation workflows
FAQ
Frequently asked questions
- Does Make have a native Kawaa module?
- Not yet. A dedicated Kawaa app for Make is in development and is not published in the Make app directory. Use Make's built-in HTTP module to call our REST API in the meantime; it works in any scenario today.
- How do I handle verification errors in Make?
- Use Make's error handling features to create fallback routes or retry failed verifications. Send the Idempotency-Key header from the setup steps, so that retrying a request Kawaa had already accepted is not charged twice.
- Can I schedule bulk verifications?
- Yes, combine Make's scheduling features with iteration modules to process large lists at set intervals.
Verify emails in your Make scenarios
Get started with 100 free verifications. No credit card required.