New look and feel, same great service? Think again. There's more to our recent rebrand of Cisco Spark than initially meets the eye - in fact, there's quite a lot to like about our makeover, including some key things specifically for you as a former Spark/now Webex Teams developer and an upcoming refresh of a familiar Webex Meetings portfolio for existing Webex Meetings developers. Take a tour of the top three developer takeaways for our new rebrand,  excited for our next evolution together. It's a whole new era for our dev community! What's in a Name? As Shakespeare concluded, a rose by any other name would smell as sweet. So why are we also changing the name of Cisco Spark for Developers to Cisco Webex for Developers? Because we've combined the best of both worlds. In this new environment of cloud-based collaboration technology, our mission is to connect teams with a single, open, secure, interoperable, intuitive cloud platform. We changed the name to reflect how we've combined our separate meeting, calling, and team collaboration solutions into a single, integrated suite. So welcome to Webex for Developers! And for those submitting integrations and bots to the Cisco Spark Depot - welcome to Cisco Webex App Hub, a central hub to discover app experiences on the Webex platform. Stay tuned to see what new Webex Meeting integrations we add to the Webex App Hub. New Webex Meetings APIs Are on the Way Heads up: Soon you'll be able to easily add powerful Cisco Webex Meetings capabilities to any or all of your apps or services using new modern RESTful APIs. Our initial release coming this summer, will enable you to perform key tasks, including: Authentication: Retrieve tokens needed to call other API's User Management: Create, delete, and retrieve host accounts; manage properties Scheduling Meetings: Schedule, edit, and list meetings Site Privilege Retrieval: Retrieve info on enabled features and privileges Additional Key Functionalities and APIs A fresh platform, several new API's, and that's not all - for us, this is only the beginning. Moving forward, we'll continue to build momentum with additional functionalities and API's across the Webex platform. So, stay tuned, and make sure to check back here for more dev-centric updates! Questions about the rebrand or what it means it means for you as a developer? Join our Cisco Webex developer community, visit Webex.com for more product information or follow us on Twitter. ... View more

With the recent launch of the Cisco Spark Depot, the Cisco Spark Depot replaces the Cisco Spark for web integrations. So you will no longer see the Add Integrations option in Cisco Spark for Web. In each room, you will now see a link to the Cisco Spark Depot. Check out the Depot for all the latest integrations and bots for the Cisco Spark app. The Cisco Spark Depot includes the same integrations that you used to access using Cisco Spark for Web, and more. Integrations that you've already set up using Cisco Spark for Web will continue sending you notifications as configured until November 30, 2016. On November 30, 2016, we will ramp down those integrations and they will stop sending notifications. We suggest you to replace your existing integrations with new integrations from the Depot immediately after November 30th. It takes only a few minutes. If you enable the replacement integrations before November 30th, you may get duplicate notifications: one from the Depot integration and another one from the integration that was set up using Cisco Spark for Web. Incoming and outgoing web hooks will be available soon from the Depot. Visit the Cisco Spark Depot today! ... View more

This update applies to those sending or retrieving message attachments using the Spark API. Download and upload limits of message attachments are limited to 100MB in size - this effectively means you can upload a file 100MB or smaller, or download a file 100MB or smaller, but won't be able to upload OR download files that are larger. Larger files can be uploaded or downloaded via the Spark clients, this is specifically an API limit intended to prevent oversaturation of resources. Previously we documented files 2GB or smaller were supported, but that limit had to be scaled back after reviewing traffic patterns and load averages. We focus on providing you the best experience and we apologize for any impact this has on you, your business and customers. We are working closely with teams to ensure any changes are known in advance. If you have any support questions, feel free to reach out to us at devsupport@ciscospark.com or join the DevSupport Spark room. Follow us on Twitter to keep updated. Related blogs: Downloading a File from a Spark Room Rate Limiting with Spark API Uploading Local Files to Spark - Spark for Developers Team ... View more

This update applies to those using the People API. We are making enhancements to support one’s own avatar. This will be available in the coming weeks with more details. We focus on providing you the best features and experience. If you have any support questions, feel free to reach out to us at devsupport@ciscospark.com or join the DevSupport Spark room. Follow us on Twitter to keep updated. - Spark for Developers Team ... View more

Hello everyone, We have received feedback from our growing partner community about Admin APIs. We are happy to announce the upcoming availability of Admin APIs. You may tentatively see them on the Spark for Developers portal in the next few weeks. With Admin APIs, an admin will be able to provision a user, assign roles, assign licenses, and view license usage of an organization. We focus on providing you the best features and experience. If you have any support questions, feel free to reach out to us at devsupport@ciscospark.com or join the DevSupport Spark room. Follow us on Twitter to keep updated.   - Spark for Developers Team ... View more

Hello everyone! This update applies to those using the People API. We are adding additional attributes to the /people resource. New attributes include firstName , lastName , and timeZone information of the people. We focus on providing you the best features and experience. If you have any support questions, feel free to reach out to us at devsupport@ciscospark.com or join the DevSupport Spark room. Follow us on Twitter to keep updated.  - Spark for Developers Team ... View more

TechCrunch has once again Disrupted New York and they took Cisco Spark and Tropo with them. In a race to be the biggest and brightest tech startup, innovators from all over converged in The Big Apple to realize their dreams by building their apps and pitching their ideas in front of a crowd of peers and a panel of judges at the 24-hour hackathon. Among those innovators were the brilliant minds who decided to build upon Cisco Spark and Tropo APIs. Take for example Irene Chang who mashed up Spark with IBM’s Watson to create a chatbot that will pretend to be you when you’re away from the keyboard! Or the CrowdBuilder crew who used Tropo to build an app that will promote events. Check out this MAILBOT app that integrated Office365, Watson and Spark to summarize your emails so you can provide vocal input so that MAILBOT will create professionally formatted email responses, all flowing through Spark! FaceTech focused on safety and security, using Tropo and facial recognition to send safety alerts when unfamiliar faces are at your door. Rapid Feedback Club integrated Watson and Spark to provide transcription of meetings in progress into a Spark room. Teams with the best use of our cloud APIs won DJI Phantom 3’s and Sphero BB-8’s: FaceTech, Rapid Feedback Club and MAILBOT.  Take a look at these eleven submissions using our APIs. There were tons of things to talk about from TechCrunch Disrupt New York, but a picture is worth a thousand words, right? Here are some pictures and tweets from the event that caught our attention. Awesome chatbot from @TechCrunch #techcrunchdisrupt built on @CiscoSpark https://t.co/2TxWUbkEoX — Jonathan Rosenberg (@jdrosen2) May 9, 2016 Move over Hooli, @CiscoSparkDev and @Tropo #APIs taking over #TCDisrupt this weekend! https://t.co/flLZQPX3cG #sms #chatbot #CiscoSpark #in — Justin Ramirez (@justinthetechie) May 8, 2016 #HackDisrupt enjoying the hack pitches. Considering the short time span pretty cool hacks from everyone. pic.twitter.com/I791148ExE — Chris Norman (@voipnorm) May 8, 2016 Cisco was also at the conference talking to developers and business minds alike demonstrating our developer friendly APIs, SDKs and a Spark connected SX10. Also, atendees got to learn about our Spark Innovation Fund. We are excited to see what TechCrunch Disrupt San Francisco has in store. Will we see you there? Be sure to follow us on Twitter to see where we'll be next! ... View more

Hello everyone! This update applies to those using a query parameter to display a SIP address for a Room. The ability to request a SIP address for a room has been removed from the /rooms and /rooms/id API call. It was a pre-production feature that had to be scaled back. Although we don’t anticipate or plan for these events, we would like to mention what we are doing to ensure this doesn’t happen in the future without warning. We are continuing to look into this and will make the feature publicly available once we have identified the best way to support it. If you’re using it in your application, it may change without notice. We will do our best to communicate changes on our blog page or on Twitter. We’ve built a number of RESTful APIs so that you can easily request data and set actions. We focus on providing you the best experience and we apologize for the impact this has on you, your business and customers. We are working closely with teams to ensure any feature changes are known early. If you have any support questions, feel free to reach out to us at devsupport@ciscospark.com or join the DevSupport Spark room. tl;dr: The ability to request a SIP address for a room has been removed from the /rooms and /rooms/id API call. Follow us on Twitter to know when it will be available again. - Spark for Developers Team ... View more

Last weekend, over 2,100 hackers gathered at three separate events around the U.S. to build some inspiring bots, use cases, and applications using the Tropo and Spark Platform APIs. HackDFW provided students with an unparalleled environment for networking and creation, resulting in some astounding new developments. Presidio Code Camp and American Airlines Hackathon both attracted more experienced hackers to come together and solve real-world issues, while having a great time doing it! HackDFW - Dallas, TX Prize winning teams focused on connection - creating applications that: connect prospective students to a community of school advisors and contacts, enable blind and deaf users to communicate, and monitor real-time negative tweets to alert companies of potential issues that need to be addressed. American Airlines Hackathon - Austin TX HackDFW - Dallas, TX Members from the Cisco Spark, Tropo and DevNet team were present at each event to provide users with both education and support. Their presence enabled teams to understand the powerful capabilities of the platforms, while simultaneously acting as a resource for troubleshooting and inspiration. HackDFW - Dallas, TX Presidio Coding Camp - Norcross, GA We had a blast at each of these hackathons, and have come away refreshed and excited! If you’re feeling similarly inspired by some of the ideas and apps created last weekend, Cisco is making it even easier to create your own integration, through the $150M Cisco Spark Innovation Fund. Find out more here! ... View more

This is a guest post from Fred Nielsen. Nielsen is a long time convergence and collaboration architect working for ePlus, focused on delivering solutions that mesh seamlessly with customers' existing business environments.  ePlus is actively developing solutions that integrate the innovate functionality provided by the Spark platform into existing business processes and technology.  Contact Nielsen through Twitter at @fredless or by email at fnielsen@eplus.com For those of us who have been working with Cisco’s collaboration product offerings for any significant period of time, the emergence of the Cisco Spark product within the portfolio represented something of a brave new world.  Spark extended the reach of a powerful offering into new territory, and showcased Cisco’s distinctly cloud-first posture in bringing additional capabilities to market. Cisco took us several steps further into this bright new future last December with their preview release of a new web API allowing anyone with a Spark account to weave their tools and solutions into the Cisco Spark platform.  Rather than an off-the-shelf product that those of us who are consultants or partners could install and configure within our end-customers’ environments, the API gives us powerful building blocks to go out and create our own unique new solutions.  These solutions can be very deeply embedded into existing workflows, or be used to create a completely standalone solution with unique new capabilities.  Being in a position to create solutions from the ground up is something of a new challenge for many of us – including myself.  I wrote this article to demonstrate how simple it is to get started leveraging these new capabilities, and how one simple idea can be implemented into a powerful use case. As I started exploring the various functions documented here, I could immediately see what types of things the API allowed me to do.  I began to have lots of ideas, but wasn’t sure I had the necessary skillset needed to implement them.  Along the way I had heard a little about Cisco’s partnership with several iPaaS providers; including IFTTT, Zapier and Built.io’s Flow product – so began fiddling with the capabilities those offered next.  Each are unique, but all feature simple interfaces that allow users to quickly create Spark test apps.  What these products also have in common is that they make it simple to interconnect different apps – a message in your Office 365 mailbox can be used as a trigger to take some sort of action in Cisco Spark for example.  More lightbulbs went off and I was on my way.  What follows is an overview of one of those lightbulbs that I was able to implement in about 15 minutes – without a single line of code. Anyone who has watched a few episodes of Star Trek has no doubt seen a crew member employ the Universal Translator – a magical device which somehow translates any language, known or unknown, into perfect Starfleet English.  I’m a fan of the free browser based translation tools we have at our disposal today – but they offer a mostly manual solution to an old problem.  I had the idea: what about a function that could monitor a Spark room, and if it detected a foreign language message, simply translate it?  The obvious use case: allow participants with differing language fluencies to communicate more effectively. After looking around at different translation providers offering web service APIs, I eventually found that Microsoft Translator could do what I needed with an OAuth token and single simple HTTP GET request, for example: Translator attempts to automatically detect the source language and simply outputs back translated text in requested language as XML like so: Now, how could I implement my idea into a workable solution?  Zapier and IFTTT are both hard to beat tools for quickly building action\reaction workflows, but I needed to a few more steps and some conditional logic in my process to accomplish want I had in mind.  This type of situation is where Built.io’s Flow shines.  Flow offers a GUI interface in which multiple “Activities” can be connected together, with output from one activity feeding into subsequent steps.  You can specify sophisticated conditional logic and incorporate just about anything you might need into your workflow. I quickly assembled a new flow and dragged in the following Activities from the toolbar, connecting them together: Check the message sender – very important.  For any process that is going to post content back to the room that triggered it, keep in mind this will in itself generate another trigger from Spark.  You will want to implement a condition that prevents your process from acting on messages it creates – otherwise you may create an infinite loop condition.  In Flow one way you can do this is by hovering over a connection and adjusting its settings.  Here we modify the first connection to ensure that the personEmail provided by Spark in the triggering event does not match my process’s user.  Something else we see here: Flow makes it easy to reference parameters provided by a received HTTP request, regardless of whether they were passed via URL parameters or inside something like a JSON string (which is how Spark happens to do it): Get the content of the message – as explained by the Spark webhook documentation, for security reasons the webhook HTTP POST from Spark does not actually contain any message content, only information about the message and a unique ID referencing the message itself.  If your process needs to see what the message says, you need to use the received ID to go and retrieve the message contents.  Flow includes a built-in Cisco Spark Get Message activity, making this easy to accomplish.  Note the first time you build a flow with a Cisco Spark Activity you will need to “add” a Connection between Flow and Spark using your API authorization token, which can be obtained from the examples given on this website very easily: Get a token to use with Microsoft’s web services – Microsoft requires that a unique token be provided to associate requests to the Translation service against your account.  This is clearly explained in their documentation, and was easy to build into my workflow using the “HTTP Request” activity in Flow: Request a translation – now that we’ve got the message text from Spark, and an OAuth token from Microsoft; it’s time to ask for our text to be translated.  For that we’re using another HTTP Request activity.  This time, take a look at the pane on the right – Flow makes it easy to incorporate outputs from previous activities as variables in new activities.  In this case {{$a1.text}} [see A] is the body of the HTTP result we got when we asked Microsoft for a new token, and {{$a0.text}} [see B] represents the text of the message retrieved from Spark.  The response from Microsoft happens to contain other information besides the token itself, but also follows standard JSON syntax - and since Flow has strong support for JavaScript throughout we can grab only the token very easily by specifying {{$a1.text.access_token}}: Convert XML to JSON – as mentioned above, the response from the Microsoft Translator API is XML formatted.  As we saw in prior steps Flow can easily reference strings within JSON objects, but referencing values buried in XML strings doesn’t work in quite the same way.  Flow offers two approaches: write some code OR use the handy XML to JSON Activity.  This Activity takes in an XML string and spits out a JSON formatted object, turning the XML response we saw above into something like this: Check the translation result – here we implement one more Condition to see if we need to post a translation to the room.  The way Microsoft’s Translator works: if it determines no translation is needed, then it returns back the same text as was input, if a translation was performed then it returns back a modified result instead.  So if the result matches the original message, we shouldn’t do anything else - otherwise move on to the next step: Post translated text to the room – our final Activity will be the built-in Post New Message function, which creates a new message in the originating Spark room - based on everything we now know this is very straightforward: After enabling the flow to accept webhooks in the Flow UI, and creating a new webhook event using Spark’s API, here is our end result: Success! Now this is only a simple example, there is certainly more that could and should be done before we could call this production ready.  Some of which might even involve some minor coding, but Built.io’s product offers lots more options than I’ve shown here.  You can even construct your own Node.js code snippets and drop them anywhere into your process to tackle some of the hard stuff.  It’s a surprisingly effective solution that sits squarely in between more simplistic drag-drop offers and custom web service development – bringing some of the best of both together. I hope this opens your perspective on how very easy it is to get started developing applications with the Spark API, even for a non-developer.  Come up with an idea and try it to work it out for yourself with the many tools we now have at our disposal.  Everything I leveraged above is available free of charge for development.  Most of Microsoft’s web APIs are free to use within certain monthly limits, and Built.io and Zapier both offer time-limited trial accounts allowing you to kick the tires.  Hopefully we will see some of those vendors also introduce partner developer programs to make it even easier for us to continue learning, leveraging and advocating these types of solutions to our own end-customers in the future. ... View more