Make
The Omnivery Message Sending Make app allows you to easily integrate the Omnivery Message Delivery platform with your scenarios in just a few clicks. It comes with 5 basic modules:
- Make an API call - a universal module to facilitate API calls. Please refer to Automations API for complete API documentation
- Send Message - module allows you to send an email message from your scenario
- Parse Email - module allows you to parse input string and return an email address and friendly name
- Validate Email - module provides email validation. Use of this module requires additional settings in the Omnivery UI
- Watch for Events - a trigger module for webhooks.
Prerequisites
Before starting your integration, you will need to have an Omnivery account with an Active domain. Please contact our sales team to inquire about getting an Omnivery account.
Once you have an account with an Active domain, navigate to the Credentials menu of your domain and select the API keys tab at the top. Add a new API key by clicking the Add Key button. Don't forget to add a note to the key (for example, "My MAKE integration") so you can later identify where the key is being used.
Once the API key is added, its token will be required to set up your connection in Make.
Make an API call module
This module allows you to create your own API calls with attributes outside of those preset in the modules we have prepared for you. In general, you should be well covered with our modules, but there might be some advanced use cases where this module will come in handy (for example, passing custom variables to Send Message endpoint, etc.). This module will allow you to work with the full scope of the API as described in the API documentation.
If you intend to use the Make an API Call module for advanced management of your Omnivery account, you will need to set up a Management connection. The Management connection requires an account API key, which can be added under the Account API keys menu item. Make sure to add a note describing this API key when adding it so you can easily identify how it is being used.
Send a Message
This is your main action module that sends an email. Its main settings include the From and To addresses, subject, HTML and plain-text body. When setting up your module, make sure the From address is aligned with the sending domain you have selected. For example, if you are using make.mybrand.com as your sending domain, your From address can be anything@make.mybrand.com or someone@mybrand.com, but NOT someone@notify.mybrand.com.
Parse Email
Sometimes you need to parse a string of addresses into a properly formed list. Parse Email will do just that—an input string with comma-separated addresses will be parsed into a nicely formed list of individual emails and their friendly names (if present).
Validate Email
Email validation is a big part of email best practices. You want to make sure that the email you received is not only syntactically correct, but actually exists and what risks are associated with it. Email Validation will tell you all of that and more.
The output contains the following attributes:
- result string - The verification result: deliverable, undeliverable, risky, unknown
- reason string - The reason for the result. Possible reasons are:
- invalid_email - Specified email is not a valid email address syntax
- invalid_domain - Domain for email does not exist
- rejected_email - Email address was rejected by the SMTP server; email address does not exist
- accepted_email - Email address was accepted by the SMTP server
- low_quality - Email address has quality issues that may make it a risky or low-value address
- low_deliverability - Email address appears to be deliverable, but deliverability cannot be guaranteed
- no_connect - Could not connect to SMTP server
- timeout - SMTP session timed out
- invalid_smtp - SMTP server returned an unexpected or invalid response
- unavailable_smtp - SMTP server was unavailable to process our request
- unexpected_error - An unexpected error has occurred
- role true | false - true if the email address is a role address
postmaster@example.com,support@example.com, etc. - free true | false - true if the email address uses a free email service like gmail.com or yahoo.com
- disposable true | false - true if the email address uses a disposable domain like
trashmail.comormailinator.com - accept_all true | false - true if the email was accepted, but the domain appears to accept all emails addressed to that domain
- did_you_mean null | string - Returns a suggested email if a possible spelling error was detected (
bill.lumbergh@gamil.com→bill.lumbergh@gmail.com) - sendex float - A quality score of the provided email address ranging between 0 (no quality) and 1 (perfect quality). More information on the Sendex Score can be found here.
- email string - Returns a normalized version of the provided email address
BoB@example.com→bob@example.com
Regarding Email Normalization
It is important to note that a normalized email address is a functional equivalent to the submitted email address. You may want to log the email address as-is before it is submitted to the API for record-keeping purposes.
- user string - The user (a.k.a. local part) of the provided email address (
bob@example.com→ bob) - domain string - The domain of the provided email address (
bob@example.com→ example.com)
Suppress Email
Ensuring opt-out requests are honored and unengaged recipients are suppressed is one of the core principles of email marketing and email best practices. The Suppress Email module will allow you to automatically suppress recipients from within your scenarios.
Watch for Events
This trigger will allow you to take action when an event related to your messages occurs. The trigger setup starts with selecting the webhook or adding a new one.
When creating a webhook, you will need to select your connection, sending domain, and event type to watch for. There are 7 types of events:
- Delivered - Fired when a campaign is delivered to the recipient
- Opened - Fired when the recipient opens the message (if open tracking is enabled in the domain settings)
- Clicked - Fired when the recipient clicks on a link in the message (if click tracking is enabled in the domain settings)
- Soft-Bounced - Fired when a message delivery fails with a temporary error (for example, mailbox full)
- Hard-Bounced - Fired when a message delivery fails with a permanent error (for example, bad mailbox)
- Unsubscribed - Fired when a recipient opts out from receiving further messages
- Complained - Fired when a recipient files a complaint by marking the message as spam
The process of setting up webhooks is fully automated, and Make will automatically add the webhook to your Omnivery account and remove it when it is no longer needed.
NOTE: Submitting a webhook test from the Omnivery UI will NOT trigger the scenario, as the Watch for Events module ignores these calls to prevent unintended scenario execution.