Today we would like to introduce a brand new Fancy Hands API, the Fancy Hands Incoming Call API.  Using this API you can have your very own Fancy Hands phone number that our assistants will answer for you.  

What can you build with this?

• First Tier Support - Have us handle simple support requests. If it becomes too specialized we can transfer the caller to second tier support.
• Call Screening - We can screen calls for you, take notes for you, have basic questions answered for you, and transfer the call to you if necessary. 
• Scheduling - If you have shared your calendar with us, we can set up appointments for you without ever having to answer the phone.

Anything you can think of that starts with an Incoming Call, and we can handle it!

The Basics

Incoming Call Numbers - This endpoint is used to search for and buy phone numbers that anyone can call from anywhere in the world. These numbers can be attached to Incoming Call Objects.

Incoming Call Objects - This endpoint is used to create the Incoming Call Objects that define what the call will be like. An Incoming Call Object is a combination of a phone number you have previously purchased, and a Conversation Object that defines how the Fancy Hands assistant will lead the call.

Incoming Call History - This endpoint is used to get the history of Incoming Calls that have been received by our assistants.

Step One - Buy A Number

The first thing you need to do is search for and buy a phone number. You will be charged a flat fee for the phone numbers every month, and the monthly price is listed when you GET the Number endpoint.

Once you have found a Number you would like to purchase, you will need to POST the full number, including (+) and country code, to the Number endpoint. Once you have a number you can hook it up to a conversation in Step Three.

Step Two - Create a Conversation

Conversations are how our assistants interact with whoever is calling your number. You can have the assistants ask questions, answer questions, transfer the call and take notes. Head over to the Script Builder to see examples and build your own.

Step Three - Create An Incoming Call Object

The incoming call object brings together the phone number you purchased in step one, and the conversation you created in step two. Make a POST to the Incoming Call endpoint with these two pieces of data and your new phone number is ready to be called.

Get started now in the API Explorer! If you have any questions, features you would like added, or use cases you would like to discuss, email our developer team at [email protected].

The Fancy Hands API is constantly being updated and improved and today we would like to introduce some new features to our Outgoing Call API. 

Call Recording

You can now have the entire call recorded for quality control.  Listen as your conversation scripts play out in real life, and learn how to tweak them to get the best results. Just mark [record] as True on your http://www.fancyhands.com/api/v1/call/outgoing/ POST request and you are all set. You will be able to find a history of recorded calls in your developer dashboard.

Call Windows

Do you want to have calls only go out in the afternoon? Or how about first thing in the morning? Now you can with call windows. Just send UTC date times to [call_window_start] and [call_window_end]. Call windows can also be set days in advance.

Webhooks

If you are already using the Outgoing Call API you may have noticed you are receiving more webhook callbacks. We now send you status webhooks when the following things happen:

• Our assistants pick up the task
• The call has been placed
• The call has been answered
• The call has been transferred
• The call has ended
• The request has been completed

Now you can pass that data along to your end user, and always know where we are on the call.

Stay tuned for more updates coming shortly!

The Fancy Hands dashboard has seen a number of different iterations. At first, you couldn't even call it a 'Dashboard', it was merely an input field and a text area where you would write and send your request. Since then it has evolved to be more of a central place where you can create new requests, browse your old ones and see your usage statistics. With our latest iteration, the design has shifted to a more modern theme that places more emphasis on what's important to you right now. One of the biggest changes though, has less to do with the design and more to do with the way the front-end is architected.

Previously

Our stack at Fancy Hands is based on Google App Engine Python SDK. Built into it is Django’s templating system which works extremely well for displaying static (Ok, maybe static isn’t the right word. I think technically it’s considered dynamic since its retrieving values from a database. Let’s call it unresponsive....) content. We can fetch stuff from the database and display it, but it didn't change without a page refresh or (later on) a lot of ajax calls and jQuery dom manipulation. We wanted something that would have a more fluid user experience and also be easier to develop and extend. We chose to go with a frontend javascript framework, and the one we picked was AngularJS.

Why Angular?

Well… simply because we were already using it for small things on the site here and there. Last year we leveraged the framework to create a simple forum for our assistants. We also used it to rebuild our TeamWork dashboard. One of the nice things about Angular is that you can use it in conjunction with whatever framework you already have in place, and use it as you see fit.

So why use it in the first place?

One of the main benefits of Angular is it’s two way data binding system. Meaning that if something changes in the model, it will automatically get updated in the view and vice-versa. The beauty of this really begins to shine when you are able to get rid of all your jQuery code that targets certain id’s only to update some text. Instead, the views get updated seamlessly once the model is updated. You then are able to build views that automatically update to reflect the state of a model. For example, in the new Fancy Hands dashboard when you load up a request and send a reply to an assistant. What happens is the reply gets sent via an ajax call to our server, the server then responds with a JSON object containing a list of all the messages associated with that request (including the new one). We then set the newly retrieved list of messages as our model, and BAM, our view gets updated automatically with the message we just sent. No fussing around with jQuery trying to recreate the message template, the new message just appears as it should.

So what do you mean by Decoupling the Dashboard?

The main goal was to move from server side rendering of the templates to client-side. By doing this, we could keep front-end concerns out of the server-side logic as well as build a more fluid UI.

Angular, and frameworks like it, work astoundingly well when you have an API you can hit that spits back JSON. We fortunately already had most of our private API built for use with our mobile apps. With just a few tweaks here and there, our API could be used to power the entire dashboard and request pages.

Before, the process of rendering a page was like this: User sends request -> server makes appropriate database requests -> server renders values onto template -> server serves the fully rendered page. This often resulted in long wait (4 seconds + )periods between pages where the server rendered the template.

Now, leveraging Angular and our API, all of the view logic is done client side instead of server side. The flow looks like this now: User sends request -> Multiple (if necessary) ajax calls get sent to the server (API) -> Server responds with JSON -> client asynchronously updates each part of the UI as necessary. The great thing about this method is that instead of having a 4 second wait between pages, we can now instantly show the user an updated view when they click, and load in content as soon as we get it. The result is an app that feels a lot more fluid and a lot more responsive.

Cache Bonus

As an added bonus, we’re able to easily cache request data locally. Since we’re dealing with JSON objects exclusively, we can store the data we receive into localStorage and then load it up on subsequent visits. The result is a dashboard that is even faster since we don’t have to wait for the server to respond at all.

Try the new dashboard out now and let us know what you think!

Earlier this year, we launched an API to allow developers to build apps and provided a single developer SDK (for python). The API gave developers the ability to make a custom request using the Fancy Hands platform. This type of request allows you to submit a request in natural language, specify a price that you're willing to pay, specify the data (including datatype) that you'd like back, and a human would get right on it. 

We thought this endpoint was super powerful, and many developers agreed. This endpoint has been used by everyone from laundry delivery startups to Lipton Iced Tea's huge summer promotion.

While this API endpoint has proved powerful, we've learned from feedback and have recently launched even more endpoints.

General Request APIs

We've added fancyhands.standard.Standard, which lets you make requests in plain text and get your responses in plain text. This also includes fancyhands.request.Message so you can communicate back and forth with an assistant.

Call APIs

We've added fancyhands.call.Call which is an endpoint dedicated to making outgoing telephone calls. Developers can specify customized scripts, make a single API call, and an actual human will be making the call within seconds. The scripts can be as simple as a "Hello, goodbye" and as complicated as custom sales scripts with logic trees based on the responses we hear. We can even transfer the call to another number at any point.

Next week we'll be launching additions to the outgoing call API including:

1. The ability to record phone calls
2. International phone calls
3. The ability to specify windows when we should call (make an API call in the middle of the night telling us to make the call at 9am)
4. Lower prices for transferred calls

We'll also be launching incoming calls. This will allow you to set up the same robust scripts and use them when people call you, not just on outgoing calls.

Developer SDKs

When we launched the API, we launched with only one SDK, the python SDK. Since then, many users have built their own wrappers for other languages. There have been forks and pull requests and bugs squashed. We've come a long way. 

Now we're thrilled to announce that we have official wrappers for Python, JavaScript (Node), Java, PHP, and Ruby. There are also third party libraries for PHP, Ruby, and Go! 

We're not experts in any of these languages, so please send us pull requests!

I'm excited today to announce we're launching the Fancy Hands API!

What is it? The Fancy Hands API enables people to make apps, add features to existing applications, and build businesses using our army of assistants. For a single developer, this means she can build insanely complicated apps in a weekend (since we have real humans do the heavy lifting).

What can you do with it? Well, lots. For example, one of our developers built a mobile app that allows you to book a car anywhere in the country. It's listed with source code, along with a bunch of other application ideas, on our developer examples page.

But it's not just the indie developers. A large sales organization could build an app to handle lead generation: when a new contact hits their Salesforce it could automatically have fancy hands reach out and look into it. Perhaps a third party company could spring up and automatically connect to these sales platforms and with Fancy Hands. They could easily charge on a per lead basis.

Currently, agencies are looking at the API to power promotions for brands. They're reaching out via social media to surprise and delight customers by helping them with shopping, travel, etc during the holiday season.  So if someone tweets about being overwhelmed with Thanksgiving planning, a brand steps in and says "We'll help!" and that's powered by Fancy Hands.

So head over to our developer page, the api explorer, our github account, and we'd love to hear your feedback.

For developers, we had some pretty specific goals:

• People should be able to build businesses on the API (not just toys)
• It needed to be super friendly for developers (RESTish)
• We wanted the best interactive API docs around

What's next? Expect more endpoints and more examples. Want to get your app featured or chat about the API? Email us at [email protected]

In the beginning…

Way back in September, Recurly went down. At first, it seemed like a typical outage that would be resolved without issue in a short span of time. It soon became apparent that this was not the case, and we were unable to bill our customers for over a week. We'd soon learn that the cause of the issue was failure on primary and secondary hardware responsible for storing credit card data resulting in the permanent loss of encryption keys rendering the stored data unreachable. Even after their efforts to retrieve copies of the data from our payment gateway, we were still left missing 5% of our payment info.

As soon as we realized this was not a typical outage, we began planning steps to move off to a different payment provider to get our billing up and running again. After listing a few options, I jokingly suggested:

You know, we could just store it on Recurly and somewhere else. It wouldn't be that hard. We just collect the data, attempt to store it with two different services, and then bill the user on the first service that sticks.

To which Ted responded:

Ha! That would be funny. [short pause] Ok, do it.

Building it

Our first priority was security. We don't ever want to touch actual credit card data (it's better to leave PCI compliance to the companies that specialize in that). We use recurly.js and Braintree Transparent Redirect, so client data never hits our servers.

What was meant to be a joke became our new method of fallback for payment data. We settled on using Recurly (we didn't want to drop support for this and inconvenience all of our current customers by asking them to update their billing information) and Braintree. Without going into too much detail, our subscription process now looks like this:

If storing billing information on either provider fails, we're still able to continue processing as long as the other does not. After our user is subscribed, the rest of our code doesn't care which method was used. In most cases, a subscription is created even in the event of failure on leg of the process. We've also got the ability to migrate our subscriptions should a severe failure ever happen again.

That was a freebie

Adding Braintree as a billing provider had a pleasantly unexpected side effect. Our iOS app (coming soon) uses Braintree to collect billing information. They have a great iOS SDK that saved us a ton of time developing our in-app signup.

Final thoughts

This post is here simply to illustrate that redundantly storing your customers' billing information across multiple services is possible. When building the payment portion of your next project, consider doing this; you'll thank yourself next time one of your services is unavailable. We're very happy with both Recurly and Braintree, but we're also prepared for the next time this happens.

Fancy Hands is proud to host the New York Python Meetup Group's weekly "open office hours" event. We had a great turnout last night, complete with free pizza and beer. Programmers from all skill levels and industries got together to talk code, ask questions, and help each other out. Here's what the meetup organzier, Gloria, had to say:

This event was really great! Thanks to everyone who came out. It was impressive to have some people just hang out and eavesdrop, ask questions, and learn, while others paired off and helped each other. The free-form way that it worked is exactly what I hoped for, and I want to thank all of you for that.

We'll be meeting here at the Fancy Hands office every Tuesday at 6:30PM. Come join us. We're excited to be hosting this event. The NYC Python Meetup Group has always been a great gathering of people, and it gets better and better. For details, check out the official Meetup page here.

We hope to see you here next time.

This is a space for our developers 
to post about cool development stuff 
but they're so busy developing right now 
they can't talk about development. 

In the meantime, please enjoy this picture of a mini horse at a Mac store. 

That's right, I said mini horse in a Mac store. 

You're welcome.