Vanilla Forums: Parse API FTW!

Posted on


This is a guest post from one of our users, Tim Gunter, Senior Systems Analyst at Vanilla Forums. Tim caught my attention with a recent tweet that read (and I quote), “I. Love. @SendGrid. Parse API so damned fantastic, I want to get an “I <3 Parse API” tattoo on my FREAKING FACE!”  Later that night, our API had Tim feeling like the “Lord of the internets”.

As soon as I saw this, I had to learn more about the experience that inspired such excitement, and within hours Tim had sent me the story below…


Vanilla currently uses an external payment gateway (lets call them Acme Pay) to handle online payment processing for our hosted plans. It is pretty standard as far as mainstream “old school” payment processers go (not “new school” like Stripe, Braintree or Zuora). The API is fairly clunky and unpolished, but it gets the job done.

The Problem

One big drawback I discovered with Acme Pay is that they do not support http “callbacks” to our system, to report on things like successful/failed payments, cancellations, refunds, etc. Obviously the lack of callbacks makes the system far more difficult to manage and track. We have to poll the gateway frequently and ask the equivalent of: “hey, anything cool happening?”. This is very frustrating, but it doesn’t end there. It seems that in addition to a lack of callbacks, Acme Pay does not store actual unique records of failed payment attempts. So that data simply doesn’t exist.

I called them up and discovered that the one thing they CAN do is send emails, either to us (the merchant) or to the client, (or both) whenever a payment succeeds or fails. Ordinarily this would be nearly useless to us, since we were looking for more automation, not another manual step (receive email, look up client, manually update their records). Emails sounded like a big hassle, and we weren’t getting anywhere. Time was ticking on and the processor was still not in a working state.

The Solution

Introducing SendGrid Parse Incoming! I set up a custom domain name for billing emails and made it point to Then, I configured our SendGrid account to ping my payment processing code on a specific URL whenever any email was received on that domain. Not only do we get pinged, bur we receive a whole host of valuable information about the email in question, everything from common fields like ‘from’ and ‘to’ pre-parsed, to multiple versions of the email (with and without markup).

The code looks at the “to” address (, extracts the username portion and interprets it as a processor name (‘acmepay’, in this case). It checks that such a processor exists (our system supports multiple processors), then fires an internal event, simulating an http request, to our payment code’s actual callback handler. It passes in the body of the email ([text], specifically) as the arguments/passed parameters.

And voila! Using the power of the Parse API, we have turned a deficiency with our payment processor into a cool integration that solves our problems and, interestingly, improves our customers’ experience at the same time.

Thanks to this integration, we can also now also send our own payment confirmation emails to customers instead of allowing the processor to handle that. As you can imagine, considering the fact that I was able to easily parse those emails for relevant information, they could not have looked pretty. In fact they were nothing more than plaintext key/value pair lists. Kinda gross, and not something one wants their customers to see.

So, thank you guys for such a freaking awesome product that Just Works and is super simple.

SendGrid turns my frown upside down :)

Well, all we can say is, “You’re welcome!” And we must thank Tim and the team at Vanilla for sharing their story. We hope it inspires other developers in the SendGrid Developer Community to use our APIs in innovative ways to solve the big problems that they face on a daily basis…oh yeah, and to strive to be the next Lord of the Internets. 

To learn more about Vanilla and how you might benefit from their products, read more below, visit their site and follow them on twitter.

About Vanilla

Vanilla is forum software that powers discussions on over 500,000 sites. Built to be flexible and scalable, and with theming/integration firmly in mind, Vanilla is one of the most powerful community solutions in the world.”


Tags: , ,

Director, Developer Relations at @SendGrid. Passionate about bringing people together around things they love. I tweet at @TimFalls.

Tim Falls on Twitter

4 thoughts on “Vanilla Forums: Parse API FTW!

  1. Is there a good way to allow forwarding from a customer (say a Gmail account) to a SendGrid managed account that then relinks the email with the customer's account in a service by some identifier (ours)?

    It seems like forwarding to a particular email address like '' would work, but would we would need to then parse the whole message to get the original from address (the from emails would now be the Gmail account we mentioned above)?

    • Hi Chris,

      If I am understanding correctly, as long as you an identifier that is common between the forwarded message and what you have in your system, this won't be a problem.

      You could use the email that forwarded the message (this is one of the fields we POST to your endpoint after we parse the message) as you suggest, or you could embed some a code or integer identifier into the original message, assuming that the original message originates from your system, and then search the content for that code.

      Take a look at our Parse API docs if you haven't already, and let me know if I can help!

      • Hi Brandon.

        Maybe a better way to think of this is that there are three parties: customer #1 (our customer), customer #2 (customer #1's customer) and us.

        Customer #1 will receive an email from customer #2 and have it forwarded to us (probably a forwarding rule in their mail provider like Gmail). We would like to parse the email headers and body to tease out the email addresses of customer #1 and customer #2. This allows us to use the email addresses as a key to do the following:

        1) find customer #1 in our customer database
        2) find (or create) a record for customer #2 that is associated with customer #1
        3) create a record of the communication that customer #2 sent in the first place

        I imagine we could potentially do this by looking in the headers or body, but I am guessing each mail provider that does the automatic forwarding will do it differently (or maybe not?).

        Any thoughts or help on how to do this would be greatly appreciated.

        If it would be easier to talk about this live I am more than happy to. How do I get in touch?


  2. This sounds great! We haven't used the parsing API yet, but are hoping to.

    One question – how do you handle the security? Eg. anyone can send an email that appears to come from a specific email address, so could somebody spoof an email to you and make your system think it had received a callback? I'm guessing that this is probably something that the Sendgrid API handles for you automatically – perhaps using DKIM or SPF or something like that? Would love to hear more info about this part of it.



Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>