HTML content passed back from the resolver URLs can contain the following "magic strings" that will be replaced when the email is sent:
String variable name
The email address of the user the email is being sent to. If the email is being sent to multiple recipients, each recipients's email will still be encoded in the individual copy of the email they receive (even though they still see the email was sent 'to' all recipients).
URL-encoded email address of the recipient. Useful for URL query strings.
The _id of the message (that can be fetched via the API)
The full name of the person you're emailing. Will be blank if there is no name associated with the email address.
URL-encoded version of the name. Useful for URL query strings.
Email address of the sender.
URL-encoded email address of the sender.
Let's say you're building an SDK integration that inserts a link to initiate a chat between the sender and each recipient. The HTML could look like this:
<a href="https://mychatservice.com/createChat?sender=!!!SENDER_EMAIL_URL!!!&recipientEmail=!!!EMAIL_ADDR_URL!!!&recipientName=!!!RECIPIENT_NAME_URL!!!">Let's chat!</a>
(notice that here we're using URL-encoded variants of the variables)
Then Mixmax user [email protected] inserts your chat link and sends an email to two people:
When the email is sent, Jim Ellis will get:
and [email protected] will get:
Notice that the recipientName is blank since [email protected] doesn't have a name in the 'to' field above.
For several APIs, Mixmax makes an AJAX call directly from the user's browser (via AJAX) to your server, for performance.
CORS and HTTPS
Requests include an
x-timezone header indicating the current user's time zone. The value will be a time zone name such as
When developing locally and using your slash command for the first time, you might see the following error in the the Chrome console:
This happens because the sample codebases (e.g. Giphy) use a self-signed HTTPS certificate. HTTPS is required because the requests for your Integration API endpoints are originating from an HTTPS url (https://compose.mixmax.com). Here's a workaround:
Mac OS X:
Quit Chrome and relaunch it with the following Mac OS X command:
open -a Google\ Chrome --args --ignore-certificate-errors . This will temporarily disable SSL certificate warnings for that Chrome session.
Opening a new tab to special URL "chrome://flags/#allow-insecure-localhost". Disable setting "Allow invalid certificates for resources loaded from localhost". (Reference - http://superuser.com/questions/27268/how-do-i-disable-the-warning-chrome-gives-if-a-security-certificate-is-not-trust)
Updated about a year ago