Describe Send With SES in one sentence.

Send With SES makes it easy to store and understand all your user data and send them targeted messages.

Describe Send With SES in a bit more detail.

When a user signs-up on your web or mobile app, you insert their details (name, email, number, etc.) into Send With SES. Thereafter any action done by that user can be inserted and tracked in Send With SES. For example if a user adds 'red shirt' to their wish-list, you attach the tag 'red shirt' to that user. All of this is done using the 'Send With SES Contacts API'.

You can then filter your users using a combination of tags to send targeted messages (Emails, SMS, OTP's).

Messages can be sent manually via the dashboard or programmatically by calling the API or by using workflow rules. For example you can trigger a workflow as soon as a particular tag is added to a contact.

Send With SES integrates with your own AWS account to send messages. Why? Because AWS is unbeatable in terms of cost and message reliability.

Explain Send With SES with one picture.

What tools does Send With SES replace?

Send With SES has three core modules. Here's what they replace.

It is important to note that the primary goal of Send With SES is to cut the cost and complexity of similar tools. It is by no means a feature-by-feature replication of the tools it might replace.

Should I switch to Send With SES?

Send With SES adheres to a minimal agenda which focuses on a few core features done really well. You should not switch to Send With SES if you have lots of 'edge-case' requirements and you should definitely not switch to Send With SES just because of it's low cost. If something is working for you don't change it.

How scalable is Send With SES?

Send With SES operates on a globally distributed and scalable server infrastructure allowing it to handle very high concurrent message traffic. Our back-end infrastructure spreads across three clouds (AWS, GCP, Cloudflare) and is designed for >=99.95% uptimes.

Does Send With SES offer any inbox delivery guarantees?

Short answer: NO.

Long answer: Send With SES forces some industry standard best practices upon you like having a domain with SPF, DMARC, DKIM records in place before you can send emails. While these practices create trust with email service providers, the ultimate decider in inbox placement is the content of your email. Email recipients are only too happy to mark unsolicited emails as spam or click unsubscribe, resulting email service providers banning you.

If you are a genuine sender, our best practices along with our InboxVISA™ tool helps guide your emails safely into user inboxes.

Ultimately, the only one who can guarantee safe inbox placement is YOU.

API rate limits?

This is the rate at which you can call the Send With SES Contacts API. This API is usually called to add/update contacts and to attach/detach tags (metadata) to contacts.

For example, a rate limit is 300 requests/minute lets you do a steady rate of 5 calls per second or a single burst of 300 calls in one second or anywhere in between. The total API calls must not exceed 300 in 60 seconds.

NOTE-1: API rate limit is a soft limit for paid plans, meaning you can do short bursts that exceed the rate limits as long as you are not abusing our systems. Write to us if you are not sure.

NOTE-2: API rate limit is independent of your Email/SMS sending rate. Email/SMS sending rates are determined by AWS. For example, if your AWS SES email sending rate is 250/second, you can send up to 250 emails per second even if you are on the 'Free Plan'.

Data retention?

Data retention only applies to idle accounts. An idle account is one that has not sent at least ten emails or sms in the last 60 days.

Your contacts and contact meta-data (tags, events, etc.), campaign statistics, email templates, images and files - all count towards your data and they may be deleted in case your account is idle.

When can I not use Send With SES?

Send With SES integrates with your own AWS account to send Emails and SMS. Opening an AWS account is free and AWS's simple email service is unbeatable in terms of cost and reliability. As of now you cannot use Send With SES without an AWS integration via the IAM Full Access Role. Why?

Why does Send With SES need the IAM Full Access Role?

In the early days of Send With SES, we asked full access permission only for SES and SNS. Send With SES is in a constant state of development. As we kept building the product we wanted permissions for S3 to store email images and SQS to queue email delivery notifications for further processing. Sometime later we wanted CloudWatch access to hold and process SMS related delivery notifications.

We also expected AWS to introduce breaking changes and wanted to be ready in such cases. Not surprisingly AWS sent everyone the following message a few months ago. (They later rolled backed on this requirement.)

"We are reaching out to notify you that AWS Managed Policy is making a change that will require your action. AWS Managed Policy is deprecating the managed policy "CloudWatchFullAccess" and replacing it with "CloudWatchFullAccessV2". After December 7, 2023, "CloudWatchFullAccess" will no longer be supported."

How do we provide an uninterrupted and seamless experience to end users when we have to constantly keep asking them to add specific permissions every now and then. This was not at all user friendly. Both end-user experience as well as product development suffered.

So we decided to ask only for one permission - IAM Full Access.

Some people were/are unhappy. Somehow their assumption was, "If we give you IAM Full Access you will misuse it.", or, "Your servers will get hacked and those hackers will do something bad." Understandably, these are valid assumptions, no different from, "Do not build a flying machine because it might crash."

We believe transparency and a proper explanation will convince some people and no amount of explanation will convince other people. To those people who are considering to use Send With SES, this is how we handle things.

1. Send With SES accesses your AWS Account by requesting a set of temporary keys using the 'IAM Role' provided by you. This is the recommended best practice by AWS. No third parties can access your account.

2. IAM Full Access is something similar to full admin access. It gives Send With SES the power to provision any resource within your AWS Account. However Send With SES only provisions resources which are required. Currently these are - SES, SQS, SNS, S3, Pinpoint, CloudWatch.

3. You can delete the IAM Role at any time to prevent Send With SES from accessing your AWS Account.

4. It is highly recommended you create a separate AWS Account exclusively for Send With SES. This way you can be sure that any resource launched within this AWS Account has been provisioned by Send With SES.