New API keys in Mandrill by default have full access to your account - can you customize? - email

In Mandrill, if you create a new API key and do not limit its API calls, whoever you give that key to can use it to log into the web interface with full access - billing information, account information, the works.
After playing around, it looks like you can disable the web interface login functionality by ticking "Only Allow This Key To Use Certain API Calls" and then selecting at least one API call. Doesn't matter which one.
So I can give full access to the account, or completely disable their ability to log in. Is there any way to customize this further? I would like to be able to limit users to the outbound/inbound UI, or at least prevent them from having the ability to charge many thousands of dollars to the attached credit card. For clarification, my use case is to distribute API keys to contractors or vendors so that all email gets sent through a single account.
I have found very little official Mandrill documentation on this. The only thing that seemed relevant is that if you have a Mailchimp account, you can instead send users there and use the "View Mandrill Reports" functionality. I don't have Mailchimp (nor do I need it), so this seems like an unnecessary hacky workaround.

Different levels of access, other than limiting API calls for API keys isn't currently possible as described in the Mandrill KB here. If someone has access to the web interface, they have access to the account as a whole. This may, of course, change in the future, and would be documented on the blog and in the KB.

I believe you could also restrict access to the web interface by setting up two-factor authentication?

Related

Is PayPal's Message Centre available via an API?

I am working on a project and my clients want to have the Message centre of Paypal integrated into their system so they won't need to log in every time on PayPal account to check their emails and reply.
I can not find any available option on their developer portal for a call similar to that. But I thought to ask here as may someone had better luck finding that.
Much appreciated.
There is a customer Disputes API for handling that part of backend administration. This is typically only useful for large/enterprise merchants.
Other things require logging into the account. User logins with specific/limited roles can be created.

Finishing Whatsapp Business API Setup

I came from a similar state in this question.
My objective is to reply to interested customers via whatsapp messages. I'll use a very special setup, so I'll be using the API.
Reasons:
With not to pay anyone other than container hosts
Solution with custom API
Customer doesn't like any extra costs
Just like user noboundaries, I see the numbers, but I cant get the certificate
User Navjot Singh has explained I need to create a "business api account"
I tried just that, put out all my contacts and stuff, in this site.
They did respond yes, but only with pointless instructions, since I wish not to contract any messaging providers. I had taken a look at it, but they charge a very expensive price beyond the $0.005 whatsapp will charge. Also, the solution I'm creating requires messages to be sent programatically, and the partners don't seem to provide the correct solution.
So, I wish to skip into using the api. I followed the appropriate guides:
Getting started
Phone Number
I already got some things done:
two phone numbers (one of them for testing) with whatsapp business;
company has been verified, with domain
have business management account
local environment with docker
I can access the local environment and I have set an user account and the admin acount. I can log into those via the API, since postman can ignore certificates, but in order to proceed I really feel like I need that certificate.
So to sim up I guess I need help creating the whatsapp business account for my customer. Any advice?
Also i'd appreciate any other helpful insight or feedback. I really feel lost and I don't see a place where I can talk to people trying to do the same thing, or doing this is much of a madness after all?
thanks for getting to read until here, and I apologize for my non natural, almost broken English.
Hi I wanted to start big in stackOverflow but I fell flat.
About the subject at hand, westerday I dwelt deep into the rabbit hole.
For most companies, you actually are forced to work with a provider, such as twllio or messagebird. They act as intermediary between the facebook business and the whatsapp business api.
Some of they offer messaging separated from whatsapp api setup I still need to take a look into it, but for those who are trying to set up whatsapp business api on their one, it seems as of november 2020 it's not possible.
please check out:
respond.io's guide
blog post from take.net PT-BR (google translate didn't like me trying to translate this to English)

Does SendGrid support double opt-in as a feature?

Does SendGrid support double opt-in to Lists as a feature or is that something we will have to implement for ourselves?
https://sendgrid.api-docs.io/v3.0/contacts-api-recipients/add-recipients
It doesn't appear to me to be anywhere in the docs, but I thought I'd ask in case I missed it.
Not as of the current date; I asked their support staff and received the following answer:
Double opt-in needs to be implemented by you in the form/page you're subscribing your recipients. The confirmation email can be sent through SendGrid.
For Marketing Campaigns we have the SendGrid’s WordPress Subscription Widget that makes it easy for people visiting your WordPress site to subscribe to your marketing emails;
or Building a SendGrid Subscription Widget.
I got this answer from their support. It turns out we have to implement it by ourselves.
The double opt-in functionality is not something SendGrid provides as
we expect our customers to handle any opt-in practices on their side.
We apologize for any inconvenience.
SendGrid will be GDPR compliant by May, 25, 2018. Please note that
SendGrid does not – and does not currently have plans to – use servers
or data centers in the European Union to process email. Thus, SendGrid
cannot restrict data to the EU. However, neither current EU law nor
the GDPR require this. Instead, what is required is that SendGrid must
provide "appropriate safeguards" for data that it hosts and processes
on its US servers (see Art 46 of the GDPR here). SendGrid offers a
Data Processing Addendum (DPA) to provide such adequate safeguards,
which includes provisions for when GDPR goes into effect.
More info on GDPR can be found here. Our DPA can be reviewed and
signed by filling out the information here.
They do not support it. I asked support many times, which is a strange as it would seem a company of that size could spare the dev resources to build a feature that literally all of their customers need.
However, https://sgwidget.com is a third party product that provides double opt in functionality for Sendgrid accounts.
Full Disclosure: I am a developer at SG Widget.
No, indeed still today, they do not. Not in their forms, nor in their API is there simple, flip-switchable support for double opt-in. But, with email automation fairly recently implemented in their marketing services ("free" and "advanced" plans, not "essential") you can send an automated email directly upon sign-up.
My solution is to have 2 lists for new contacts, where one is a "pre-confirmation" list and the other being the "real" list. Here´s a way to use automation:
Create initial signup form, either via their sparse Web forms or via your own, using HTML/JS/PHP and API endpoint:
Create 2 separate lists, one for "pre-confirmation" emails and the other for people who confirm their addresses.
Make the form sign up new contacts to the first list, "pre-confirmation".
Create a marketing automation flow that triggers upon new signups to the "pre-confirmation" list. Make the automation trigger an email that contains a button or a link with the following link structure:
https://yoursite.com?email=user#email.com&passphrase=[phrase-you-set-manually]
where ?email= is your user´s email, substitute this in the email template/design by {{ Sender_Email }}
where &passphrase= is a phrase long enough to not be guessed. Since you only have one single email design here, and you can only enter one single phrase, unless you make a script or a hash, you make it difficult enough for people to think it was generated by a server :).
On your server/application, yoursite.com, use $_POST['email'] and $_POST['passphrase'], or whatever you name them, to validate the email clicks from your list and then enter all validated emails to the correct list using the PUT
/marketing/contacts endpoint.
you may also have to delete the user from the previous list, using DELETE
/marketing/lists/{id}/contacts, but I do think that the PUT /marketing/contacts takes care of placing the contact in only the lists specified in the list_ids field.
once the contact has been entered into the correct list, you can also have a marketing automation set up for that list, which sends him/her a welcome message.
This method takes care of double opt-in for SendGrid without using one single email credit from the Email API (transactional plan). The only catch is that we utilize one initial and one second/final list to achieve it.
Note: the initial sign-up message that here acts as the "confirm your email" message, will be tied to the first list and will require a marketing unsubscribe link in the footer. Make it clear in the bottom of the email that it is a temporary list, to not get any spam complaints. But it will not be an issue, as we wont be sending to anyone in that list except for this initial time. Unless you have a user who enters his/her email twice, after some time of inactivity when they forgot they already signed up. That could happen. But it´s a separate issue.
I think this is possible by switching the flow of a typical email subscriber. When the user clicks your subscribe button, instead of calling the sendgrid members/contact PUT api to add to your list, send an email with a link to a URL of yours that will then trigger the members/contact PUT api call.
Not sure what stack you are using but I was able to build something like this with next.js utilizing their api routes

Social Network (Facebook, Twitter, etc) User Account Integration (duplicate scenario)

So there are definitely many tutorials out there regarding how to integrate various individual social network authentication/registration into existing user accounts. But the scenario I can't seem to find out much information about is if a user signs into your account with different social network credentials. For example:
Scenario #1
User registers on site using site's authentication.
User then signs in/registers on site using Facebook Connect.
User then signs in/registers on site using Twitter.
How do I integrate all of these into one account?
Obviously once a user is registered, they can add other social network associations in the account settings pages. But I am more concerned if they register via the other social network not remembering they are already setup.
My general thoughts are trying to figure out a way to use the "username" or email to try and guess and present the user a way to combine accounts right there.
Anyone have any thoughts?
following up -
if your users can't remember that they've signed up previously, well, best of luck to them in general ;)
much as you described, i'm planning on giving users the option to link additional accounts once they have signed in by one means or another.
but as far as cross-checking, there's only so much you can do. many social network APIs do indeed provide email addresses (once you've busted in through OAuth) but these may be accessible only if a user has elected to make his/her address public, which is not guaranteed.
also not guaranteed is that the user used the SAME email address for each social network account, so even if you manage to retrieve an address it may or not be of any use to you.
finally, if you find matching email addresses via such means, it might be advisable to prompt the user to link accounts rather than assume he/she wants this done automatically. some people like to maintain multiple personalities. i.e. "it looks like you are also signed up with twitter - do you want to link your accounts? it will make your life seem worth living."
you might consider offering incentives to link user accounts or to provide an email address (up to you of course to figure out what these might be, based on the functionality of your website).
solution i am working on, database-side, is to maintain multiple accounts and then if link information is discovered by various means, said link is indicated in a lookup table.
an alternative is once you find a link, attempt to combine all relevant entries for the multiple accounts into one account entity - all i can say about this latter approach is that i would do so with caution as there could be a formidable level of complexity depending on the user's activity level and the complexity of your database schema.
in my (mental/actual) namespace a user who registers the old-fashioned way has a 'standard' account and one who uses a social network has an 'alias' account. then the goal becomes to define where the alias is supposed to point, i.e. create the lookup such that a subsequent login via either means retrieves the relevant information for both accounts (with a preference for displaying personal data for the 'standard' account).
btw i figured out how to make twitter OAuth behave since my last post - you can look at my other answers for details if you're interested.
JB
hi matt,
i'm working on the same problem right
now.
assuming the user starts with regular
site account (which is not
necessarily safe to assume if he sees
all the pretty "connect with XXX
network" buttons!!!), you can use
either OAuth or the javascript APIs
(facebookConnect or #anywhere -
haven't fully figured out the latter
yet and i'm not sure I recommend it as
I don't think it provides as rich an
API as do the backend libraries) to
login to the other sites.
the APIs should return certain
information after a successful
login/redirect from the social network
- such as the user ID and an ACCESS TOKEN which you can then store in your
database in some capacity associating
your 'actual' application user with
the ID of the social network.
when the user returns to the site, you
can then
1 verify cookies set by the social
network services (various schemes
typically verifying a signature, based
on sha1 or md5 hash of your
application data - by which i mean the
data you get when you register your
app with twitter/facebook, typically a
consumer key, application ID, etc. -
with the received cookies) so you know
the user has logged in with the social
network
2 find your database entry association
as described above
3 login your user manually based on
the assumption that facebook/twitter
connection is secure.
caveat: this is only as secure as your
implementation (or as secure as
facebook/twitter's implementations, if
you prefer...)
although twitter's OAuth does not
currently seem to work quite right,
their general description of the
process is pretty informative:
http://dev.twitter.com/pages/auth
good luck.
J
I have been contemplating adding FB auth to our app, but we know that our returning users might click it and complete checkout for a new item, and then be surprised to not see any of their existing orders. To solve this, when a user clicks the 'Login with Facebook' item, we are using that click to fire a dropdown menu with two options:
[ Login with Facebook ]
[ Create new account ]
[ I have an account ]
If the user clicks 'I have an account' we send them to FB auth and return email from FB to our app. We compare that email to our existing users. If we match, we add the FB creds to the user. If no match, we throw an alert:
The email you have with FB does not match any of our accounts. To log in to your existing account, login with your email below, or update the email in your Facebook account
This allows the user to create a whole new account, if they want to keep them separate, without needing a new email service. While this is an edge case, it is a feature.

Facebook Connect Implementation questions

I hope this is allowed but I have a number of questions regarding Facebook Connect, I'm quite unsure on how I should approach implementing it.
I am working on a live music type service and currently have user registration, etc. If I were to implement Facebook Connect alongside this, would I still be able to email the Facebook Connect users as if they were on my database?
Also, would it instead be possible to let users who have Facebook "link" their accounts once registered so I am able to give them the benefits of sharing via Facebook and inviting friends while still having an actual registered user on my system.
I have tried to read up answers to the above questions but what I've found is quite ambiguous.
Thanks, look forward to your views.
Facebook's documentation process is very poor, so don't feel bad about having a hard time getting started. Their wiki-style approach to documentation without any real official documents tends to leave the "process flow" tough to grasp, and requires piecing together parts of a bunch of randomly scattered docs.
Facebook has an obligation to protect privacy, so they never make a user's actual email address available to application developers, through Connect or normal applications. They do have a proxied email system in place that you can use, however, you must get explicit permission from a user in order to email them. There's a decent document on proxied email here. You can get permission by prompting for it; there's several methods for doing so linked in that document.
In regards to linking Facebook and local accounts, this would definitely be the way to go. Once a Connect user logs in, you want to store that fact for that user so you can provide the Facebook-specific functionality. I would simply create a normal user account in the database for every new Connect user that came by, with it's own local id, so that you don't have to do special handling of two different types of user accounts all over the site. That being said, the account would obviously have to be marked as a Facebook user's account (I use an externalId column in my users table), and any part of the site that relied on information you might otherwise have locally would have to handle the Facebook aspect properly (such as using proxied email instead of normal email).
For existing users, you could arrange an "account link" by having a process whereby they log into FB Connect after they've logged into the site already, and you could detect that and simply add their FB id to your users table. After that, they could log in through Connect in the future, or through your normal process. I've never done this, but it should be possible.
If you write the account handling code generically enough, your site will be able to function well no matter what kind of user you throw at it.