We spend most of our daylight hours steeped in technology. We’re at work behind our laptops, on our phones or tablets, constantly switching between multiple tools and apps.
When these apps work well together, we even get some work done. But when they don’t, it’s difficult to see the value that all this technology promises.
The next time you feel frustrated with entering the same information between multiple tools, think about building an API integration.
Wait, what’s an API again?
If you don’t already know what an API is, don’t worry. We’re going to explain it here in simple terms. We’ll also give several examples of how our API can work with other tools, and how you can get started.
Note: If you’re looking to dive right in, you can find more technical information in our API documentation.
What’s an API and How Does It Work?
If you aren’t a technically-minded person, most definitions of an API probably leave you with more unanswered questions than when you started. So, we’ll try and keep this as simple and clear as possible.
In simple terms:
API stands for Application Programming Interface. When two different pieces of software talk to each other, they typically use an API to exchange information from one tool to another.
Many of the apps you use every day utilize an API in some form or another. Expedia or Kayak, for example, connect to many different airlines’ APIs to retrieve flight information, making it easy to compare and book flights. The weather app on your phone pulls the five-day forecast from a weather service using an API, too.
One popular way to illustrate how an API works is to think of it as a waiter in a restaurant. You want to order some food from the menu. The kitchen provides a service to cook you that food. And the waiter is the API — they relay the information you provide (your order) to the kitchen. The kitchen does their job, and the waiter delivers your order back to you, in the form of food. Like an API, the waiter helps exchange information between you and another service provider.
There’s another important point to consider in this illustration: the menu.
No restaurant serves every kind of food. They typically provide a limited amount of options for the customer to choose from. And it’s the same for software. An API allows only certain information to be accessed and transmitted.
As long as you can access the information you need, you can accomplish quite a bit using simple integrations.
What’s Possible with the 10,000ft API?
Our goal is to make the 10,000ft API flexible and robust enough to customize to your specific needs. And we’re quite proud of how easily our customers can work with it to build their own integrations.
Here are a few examples of custom API integrations used by our customers:
Keeping Project Data Consistent with 10,000ft + Slack + Trello + Box
“The main reason for building Job the Builder was tool overload,” says COO Robby Rigano. “We want to use the best solution for each job, rather than one tool that’s going to do some things well and some things not well. But this leads to inconsistencies across each platform.”
Job the Builder is a one-page form, where people can add information like project title, client and brand, project description, start and end dates, and the producer name. Then, four things happen:
- A 10,000ft project is opened
- A client folder is created in Box with our templated folder structure that can also sync with the desktop app
- A new board is created in Trello if you chose to do so
- A new channel is opened in Slack to discuss the project
There are also direct links to all these different tools on the confirmation page. All common fields in the tool are entered appropriately in each platform, which ensures consistency in workflow management and reporting.
Understanding Availability for Sales with 10,000ft + Salesforce + Google Calendar
Corsis, a technology assessment software company, uses our API to connect 10,000ft to both Salesforce and Google Calendar.
“Around July of 2017, our business more than doubled,” says Laura Krassner, Director of Client Services. “Our sales team was coming and asking us every minute, ‘What’s our availability? What can we do? Can we agree to this project?’ We needed a better way of providing answers.”
The Corsis team uses Salesforce to manage their opportunity pipeline. When an opportunity moves to pre-closed stage in Salesforce, the details of that opportunity are pushed to 10,000ft Plans as a tentative project.
Once the project is confirmed and a contract is signed, Sales transfers the opportunity to a confirmed project in 10,000ft.
10,000ft is synced to Google Calendar, so everyone with a corsis.com email address has their assignment visible to them, and within 30 minutes it’s refreshed and shows up on the 10,000ft Schedule.
With these integrations in place, 10,000ft supports Corsis’ entire delivery process, including staffing, scheduling, budgeting, and reporting.
Communicating Project Status with 10,000ft + Slack + Google Sheets
Another customer — a large, international mobile technology platform — built a custom integration to communicate time entries, utilization, and project health from 10,000ft in Slack.
“For us, it was really important to get the actuals and the plan in one place,” they shared. “It should be really straightforward to plan and compare actuals to see where you're at. It was a big win to go from two tools to just one.”
They created a Google Apps Script that talks to the APIs from 10,000ft and Slack every morning. Every day of the week, for the week prior, it sends a reminder to everyone if people didn't track the number of hours required for the past week.
Slack notifies people if their hours aren’t entered, and from there, they just click on a link in Slack to fix it. They also send team leads a weekly report in Slack to say who worked over 45 hours for the past week, ensuring people don't overwork or get burned out.
Another script was created for project health, using a Google Sheet with all of the details for each project, like:
- Producer on the project
- A link to Salesforce
- All planned and actual time fees
- Planned and actual expenses
- Total sum of expenses and time fees
- Project dates
- And other context about the health of the project from custom fields
They send this as a linked report in Slack to their producers on a bi-weekly basis, so they can stay ahead of any project risks and red flags.
This dashboard becomes the single source of truth. The team knows exactly where to look, and it creates an equal level of accountability because everyone has the same information.
Other Integration Possibilities
Shawn Dorman, Owner of nkahootz software design, has been working with our API since 2016. He’s helped many of our customers build API integrations when they don’t have the internal development resources available.
According to Shawn:
“Anything is possible with the 10,000ft API. Every bit of information in 10,000ft is accessible in the API, as far as I’ve seen.”
So, if you’re curious about whether our API integrates with another tool not listed here, reach out and ask. There’s a good chance you can make it work.
How Long Does It Take to Build?
Of course, none of this happens overnight. Building any integration takes time and effort. And it’s important to budget accordingly.
How much time it actually takes depends on the type of integration, and whether you plan to build it internally or hire someone like Shawn.
Many customers report between one to three months of work using their own internal team, outside of their normal workload. Although, if you can dedicate the time and budget for someone full-time, that process speeds up quite a bit.
Job the Builder, for example, took Fancy Pants Group six months to build from inception, outside of their normal client work. With a full-time developer, however, they estimate it would’ve taken only three months to build.
What if you don’t have the internal resources?
If you don’t have an internal development team, or want to outsource the project, Shawn Dorman estimates “between 30 to 45 days on average, from the time everything’s approved to being ready for testing, depending on the project.”
The bottom line?
- An internal developer working on the side takes an average of 3 - 6 months
- A dedicated developer working full-time takes an average of 1 - 3 months
Shawn recommends understanding your workflow ahead of time, to determine what you want to accomplish with an integration in the first place.
“Sometimes people approach me and say, ‘Hey, we have this new package, we want all the data moved over to this other program, so we can work with both tools.’ But they don’t have a workflow in mind, and that causes extra work. Or it may cause work to be missed that really needs to be done. Or worst case, it causes them to pay for something to be done that may not have worked to begin with.”
You may want to pull time entry data from 10,000ft into another tool for example, but what specific data do you need in the context of how your work? How do you want the time entries displayed? What information is needed (and what isn’t)?
As you plan and budget your integrations, think about your workflow and who will be doing the work, so you don’t spend more than you need to.