Resources · Make integration

DQE Make integrationAutomate DQE with Make.

Tired of bad contact details reaching your CRM? The DQE Make integration gives you 4 action modules to check an email, a phone number or a postal address inside an automation. This guide connects your account and walks you through a first scenario, step by step.

Verified Trustpilot reviews · AI, automation & growth agency

What you can automate

What does the DQE Make integration do?

With the DQE Make integration, a Make scenario sends a contact detail to DQE and gets the check back. A scenario is the automation you build in Make, a chain of modules; a module is one brick of that chain. DQE brings 4 of them, all actions, so the data always comes from another app first.

Screen form sign-ups before they land in the CRM. A lead fills in a form, another app starts the scenario, and Check an Email looks at the address before anyone writes to it. Your sales team works from the output instead of guessing.

Catch shipping addresses that will bounce. For an online store, Check an Address runs on the address of each new order, so the logistics team sees the doubtful ones before the parcel leaves.

Keep a call list usable. A support or telesales team can pass each new number through Check a Phone Number before it reaches the dialer.

What the page cannot promise: the Make documentation for DQE is marked as limited, so it does not describe the fields each check returns. Run the scenario once on a real contact and read the result before you build on it. The Make troubleshooting guide helps when a run fails. DQE may also exist on n8n; the n8n vs Make comparison lays out how the two tools differ, and the Make training covers the editor from scratch.

Connect

How do you connect DQE to Make?

  1. 01

    Add a DQE module

    In your scenario, click the +, type DQE in the search box and pick one of its modules, for example Check an Email. Then click Create a connection. A connection is your DQE account linked to Make once and reused by every DQE module.

  2. 02

    Name the connection

    Give the connection a name you will recognize later, such as the client or the environment it belongs to. This step is optional, but it saves confusion as soon as a second DQE account shows up in the list.

  3. 03

    Authorize and save

    Follow what Make asks for: either approve access on the DQE page that opens, or paste the key DQE gives you. Click Save. The connection now appears in the module, and every other DQE module can reuse it.

First scenario

Your first scenario with DQE

GoalWhen a new contact arrives from another app, Make asks DQE to check its email and then its postal address.

  1. 01

    Create the scenario

    Open the Scenarios page, create a new scenario and click the +. DQE has no trigger, so the first module belongs to the app where contacts come in, such as your form or CRM.

  2. 02

    Add Check an Email

    Click the + on the right of the first module, search DQE and choose Check an Email. Create the connection, then map the email that the first module passes along.

  3. 03

    Chain Check an Address

    Add Check an Address after it and map the address fields from the same contact. Each contact travels as a bundle, one item passed from one module to the next.

  4. 04

    Test with Run once

    Click Run once with one real test contact waiting in the source app. Open the bubble above each DQE module to read what came back before you plug anything else behind it.

  5. 05

    Schedule and switch on

    Set the schedule on the first module, every 15 minutes by default, then switch the scenario on. Each module run counts as one operation on your Make plan, so two checks cost two per contact.

Modules

What the DQE modules do

DQE gives you 4 modules. For each one: what it does for you, when to reach for it, and what to watch out for.

DQE1

Check an Address

Action

In Make“Checks an address.”

Hands a postal address to DQE so your scenario gets DQE's verdict on it before an order ships or a record is saved.

When to use it
right after a new order or delivery form arrives, when a wrong street name means a returned parcel.
Watch out
the Make documentation does not list what this module returns, so read the output of a Run once before mapping it anywhere.
DQE2

Check an Email

Action

In Make“Checks an email.”

Gives you DQE's check on an email address, a simple filter to put in front of a newsletter list or a sales sequence.

When to use it
as the first DQE step behind a sign-up form, before the contact is written to your CRM or mailing tool.
Watch out
one check is one operation per contact, so place it after any filter that already drops obvious junk.
DQE3

Check a Phone Number

Action

In Make“Checks a phone number.”

Lets DQE look at a phone number so your team calls numbers that have been screened rather than whatever was typed in a hurry.

When to use it
when leads go straight to a call list or an SMS tool, and a bad number wastes an agent's time.
Watch out
the documentation is limited, so check on a test number how DQE reports its result before building a route on it.
DQE4

Make an API Call

Action

In Make“Performs an arbitrary authorized API call.”

Opens the rest of the DQE API to your scenario, with the same connection, for anything the three check modules do not cover.

When to use it
when DQE offers a service you need and no dedicated module exists for it in Make.
Watch out
you write the request yourself, so keep DQE's own API reference open; Make gives no detail on these endpoints.
Need help

Need help automating DQE with Make?

A person reads every message.

FAQ

Questions about DQE and Make

01Is the DQE Make integration free?
Yes, on the Make side. DQE is a standard app, so its modules work from the Free plan, which allows 2 active scenarios, a minimum of 15 minutes between scheduled runs, and 5 minutes of execution per run. Paid plans (Core, Pro, Teams and Enterprise) bring the interval down to 1 minute and remove the cap on active scenarios. Every module run counts as an operation, so checking an email and an address for one contact uses two. Your DQE account is a separate matter, handled with DQE.
02What do you need to connect DQE to Make?
A DQE account and a Make account. The Make documentation lists no specific prerequisite for DQE, so the generic flow applies: add a DQE module, click Create a connection, optionally name it, then either authorize Make on the DQE page or paste the key DQE provides, and click Save. The connection is created once and every DQE module in every scenario can reuse it, which keeps later changes in one place.
03Does the DQE Make integration react in real time?
It depends on what starts the scenario, because DQE has no trigger of its own. The check runs when a module from another app feeds it a contact. If that first module is an instant trigger, the source app calls Make as soon as something happens. If it is a scheduled trigger, Make looks for new data on the scenario's schedule, every 15 minutes by default, and no sooner than that on the Free plan.
04What if a DQE module is missing in Make?
Use Make an API Call. It sends a request to any endpoint of the DQE API with the connection you already have, so a DQE service without its own module is still reachable from your scenario. Keep in mind that the Make documentation for DQE is marked as limited: it does not describe the fields of the three check modules, so you rely on a Run once test and on DQE's own API reference to know what comes back.
05Should you use Make or n8n for DQE?
It depends on the tool your team already runs. In Make, DQE is a standard app with 4 action modules, available from the Free plan, including a generic API call for anything else. Many apps also have an n8n node, so check whether DQE has one before choosing on that basis. Compare the two on what matters to you: how the editor feels, who maintains the scenarios, and where your other apps are already connected.