REST Email – How to Send Email with Links to Client URL Using RESTful API

emailrest

A client can call the following REST api URI to send an enquiry

POST /v1/businesses/{business_name}/enquiries

The enquiry can then be viewed through the following call:

GET /v1/businesses/{business_name}/enquiries/{enquiry_id}

When a new enquiry is posted, the business is informed via email. The email includes a link to the enquiry. The issue I have is that the API will add the following link to email:

http://api.com/v1/businesses/{business_name}/enquiries/{enquiry_id}

When a user clicks the link in the email, they will be incorrectly taken to the API resource instead of the client page. So I need the email to contain the following link:

http://client.com/dashboard/{business_name}/enquiries/{enquiry_id}

Noted: Above client URL is an example. Clients can implement their own routing however they want, a single page client app URL could also be used. The point is, the client URL must be exposed in the email, not the API URL.

I'm not quite sure how to get client URLs into the email.

One option would be to provide a client URL in the original POST request. Problem with this is that the client won't know the URL to use until after the POST, at which point the email has already been added to the queue.

Another option is to pull out the queueing of emails from the API and make the clients responsible for it. I don't really like this idea as client implementers will not be too happy that they purchased the API, only to then find out they then have to decide when to queue emails.

Best Answer

For a simple solution that doesn't require you to change the links in the emails, you could have the relevant part of your API respond to requests from user agents in a way that makes sense to an end user.

Have your API respond to requests with an accept header containing text/html by redirecting them to a remote resource specified by the business. Allow the businesses to set up the redirect path (with some simple token replacement) through another part of the API.

If the business hasn't set up a redirect path, serve up an HTML page containing the content of the enquiry instead of redirecting the request.

Of course, this only needs to be done for the part of the API that's linked to in the emails.

This approach has the advantage of businesses being able to change the redirect path at any time, and if a customer clicks on a link in an old email, they will get sent to the new remote resource. This also allows you to do click tracking if you want to.

Here's an example of how it might work:

  • Your client "Business A" wants to show enquiries on their own dashboard, so they set up a redirect path by making a request: PUT /v1/businesses/business_a/enquirypath, containing {"path":"http://business_a.com/dashboard/enquiries/{id}"}.

  • Your client "Business B" doesn't have their own dashboard, so they don't set up a redirect path.

  • You send out emails on behalf of businesses A and B. The emails link to the same resources that your API uses.

  • An end user clicks the link in the email from Business B. Your server sees that HTML content is being requested (rather than JSON/XML). Business B has not indicated that requests should be redirected, so the API simply serves up the enquiry in user-friendly HTML form, like the user agent requested.

  • An end user clicks the link in the email from Business A. Your server sees that HTML content is being requested again. Business A has indicated that enquiry requests should be redirected to their own server, so your API redirects the request to the path they specified.

Related Topic