Integration and API Workshop - July 2020

Hi everyone. Welcome to HubSpot's integration and API Best Practices Workshop. We are super excited that you're here. My name is Sarah Jane Morris, but you can call me sj. I lead our developer programs and our developer community initiatives here at HubSpot and again, super psyched to have you here. So let me jump into our agenda. First, I'm going to do a little housekeeping and I will share some exciting developer resource updates that we've made in the last few months with you. Then Francis and Chris on our Developer Experience team are going to walk you through a deep dive of our HubSpot APIs. Some of the changes that we've made this year, the investment that we've made in our APIs, and some of the ways that you can best take advantage of these changes. Then we'll have Tricia, who leads product on the ecosystem team here at Hub HubSpot to come in and talk about the future of HubSpot's ecosystem and truly discuss the opportunity at hand to get you all inspired, hopefully and motivated to build the next great HubSpot integration. Then finally we will have about a 15 minute session of live Q and A. So if you have questions throughout the presentation, please use the Q and A tool in zoom. You'll see at the bottom panel there. Submit your questions through that tool and we will address them during the live session in the last 15 minutes. And we encourage you definitely. Please feel free to chat with us, chat with your fellow developers, give us live feedback as you're watching these presentations in the chat panel. And just a heads up that we are recording. We're going to be sharing this afterwards but want to make sure that you are all aware that we're recording. So without further ado I will jump into some exciting general updates for our developer resources. We have a brand new developer website. It's been live for a few months now, but you may not have all noticed this new modern website. We're pretty excited about it. The homepage itself hopefully gets you where you need to be much more quickly than previous iterations of our developer website. We are constantly improving it, making sure that you have the latest and greatest stuff stats on this developer website and that it gets you where you need to go within this initiative. Building out a new developer website. We also optimized and built out brand new docs so our docs are much more modern looking on the API side as well as the CMS side on the API side. They are powered by Swagger, which is an industry standard API documentation tool. We have a much more interactive interface now with solid code examples, so we're very hopeful that the experience has improved for you on our API docs. We're also excited about our Postman collections. These Postman collections allow you to organize your requests much more effectively, they allow for faster prototyping, and there are a series of very collaborative tools that you can use within Postman to really help optimize and organize your API call experience. And we are excited that we've rolled out API clients for all of our V3 APIs. Right now they are available for use in Node, PHP and we've recently rolled out Python. They have standard functions for auth, error handling and rate limiting. Hopefully those will help optimize your development experience as well. Here they are. We will share these. These are the quick ways to get them. We'll be sharing these slides as well afterwards so you can quickly access them, but they are listed on our docs as well. I want to also point out our Academy. We have several developer facing initiatives and courses that are either live or that we're working on now, both from the CMS side and the API side. So definitely go to our HubSpot Academy. Learn a whole bunch of great things that will get you started much more quickly and also provide us feedback. What are you looking for? More lessons on what can we help you with? What will help you grow as a HubSpot developer? We're here, we want to address it, we want to build it for you. Definitely subscribe to our Developer Changelog. Especially if you're actively developing on HubSpot today, you can subscribe and get real time updates for our Changelog. We share all kinds of updates, announcements around our API client libraries, sunset announcements, API launch announcements, new resources as they become available. Mission critical things that you as a developer need to be on top of to optimize your experience building with HubSpot. Finally wanted to draw your attention to our new developer blog that we launched a few months ago. If you go to developers.HubSpot.com blog we are looking to share more and more stories around the resources you can use on HubSpot. Share more and more about what other developers are building on HubSpot, get you excited about events like this that we're hosting, share recordings from events like this if you miss them, and a little bit more context if you prefer reading rather than watching a video. Our developer blog is growing. We're actually excited if you have ideas for things you'd like to contribute to the developer blog, we are all ears so do hit us up. You can write to me directly sjmorrishubspot.com and we can chat together and see if you're developer blog idea is one that we will be excited and happy to support. Without further ado, I will wrap up now and hand over to Francis and Chris that will walk you through all kinds of goodness around our refreshed APIs and the experience around them. Thank you so much. Thank you so much for joining us again today and we will see you during the chat. Thank you.

Welcome everyone. I'm Francis, a product manager on our ecosystem team. Today we'll be taking a deep dive into HubSpot's refreshed API. You'll be hearing from myself and my colleague Chris about the following topics. Since our launch in 2006 as a marketing software company, HubSpot has come a long way. We've built everything from marketing, sales services and CMS tools, and our small autonomous teams have made it possible for us to ship these great products and their company APIs. As of last year, we had over 500 endpoints, seven teams working on public APIs, over 450 docs pages, and billions of calls being made on the platform on a monthly basis. Now that's a lot of power, but it's also a lot of friction. The same structure that allowed us to grow at lightning speed also created friction. Without a shared framework for usability consistency, our small autonomous teams were creating a lot of pain for developers. But don't take it from me. Here is some of the feedback we received at the time. We heard things like Designed for marketers to make developers miserable. One of the worst APIs with which I've had the opportunity to work with.

That's tough.

Not fair. APIs are the user interface that our developers depend on to get their jobs done. They're absolutely critical for our developer success. Let's take a look at what was causing some of this frustration. By far, API consistency was the biggest challenge facing our developers. For example, let's look at the URLs we ask our developers to use to list contacts, companies, deals, and tickets. Here we see different version numbers, different pluralizations, and different conventions. Hear that? The experience of using our world class in App UI in the app, contacts, companies, deals and tickets not only look the same, they work the same way too. The only thing that changes is the name. This becomes a huge asset for our users, gives them the confidence and context they need as they interact with more and more of the platform. Well, today I'm delighted to share that when our developers spoke, we listened. Earlier this year, we kicked off a massive effort to overhaul the entire HubSpot API. This new generation of API is designed with consistency at its core. Now, to talk about some of the new interaction patterns and how we're enforcing them, I'd like to introduce Chris Baldoff, an engineer of the Developer Experience team.

Thanks, Francis. I'm Chris Baldoff, an engineer on HubSpot's developer experience team, and I am passionate about building APIs that developers love. But for the first part of today's chat, let's pretend I'm not Chris that works at HubSpot, but instead Chris, who just started as a developer at Acme Corp. My manager pulls me aside on my first day and tells me that he's got a really important assignment for me. The board wants to be able to measure the ROI of their investment on HubSpot, and in order to do that, the HubSpot contact data needs to get integrated into the monthly Management Dashboard reporting app, which I gather to be a homegrown system. So I'm feeling a little nervous. But I ask around and find out that the Management Dashboard app is really just a SQL database. So this boils down to read contact data out of HubSpot and put it in a SQL database. It's pretty straightforward. So I plug my keywords into Google and I find my way to the HubSpot developer's API documentation, which has a page dedicated to getting all contacts. So I read up on it, I open my code editor, put on a pot of coffee, and in a little time, with some trial and error, I've got code that works. Feeling pretty good. So I take it to my boss and let him know that the contacts data is now in the Management Dashboard app, and he should be able to take that to the board, which he does, and they're happy. But they want more. They say, okay, now do the same thing for companies, deals and tickets so we get the full picture of our HubSpot investment ROI. All right, well, let's head back to the API docs and read up on companies, deals and tickets and all. While I'm doing this reading, I'm trying to think of as a developer, how can I get the most bang for my buck out of my code and make it as reusable as possible? But as I dig into the details, I'm building this mental model of all the things that are different between the API responses for the different objects. There are different URL paths. They use different JSON properties for the IDs and the lists and the way to get to the next page is different. And this is really just scratching the surface. The truth is, building this mental model has way too much complexity associated with it. Certainly there's got to be a better way. And there is. I'm really excited today to introduce the next generation of HubSpot's APIs that have been simplified and had a lot of added consistency with brand new API documentation. So let's drill in to a particular example of getting a single contact contact with ID123. So the response is pretty simple, and if we squint just the right way, we can kind of see that contacts is really just object type and the properties map is just a stretchy dictionary to hold the keys of the different fields. So this new API should be able to just plug and play for all those different object types and allow me to insert the data into the Management Dashboard app, bringing us closer to the promise of the only thing that changes is the name. Now, I wanted to make sure that I wasn't standing in front of you today selling snake oil, so I wrote some code to exercise exactly this. So this is some code that pulls the first three contacts, companies, deals and tickets from HubSpot's demo account, which you can try yourself, and prints them out as a CSV. So the interesting bits are the list of the array of different object types that we want to iterate through the API path to get the data. And that looks, that looks very familiar. And then how do we get the property values as a comma separated list? Now, obviously the ultimate end goal is to put these in a database which probably has its own schema, but CSV for illustrative purposes, will show us the fetch from HubSpot side. And this works. That's 40 lines of JavaScript that printed out the top three contacts, companies, deals and tickets, which gets us pretty close to our promise. And now I'd like to zoom in on what are some of the changes that we've made in these new refreshed APIs. All right, so back to the get a single contact example. You'll notice that the ID is called id. It'll be the same everywhere, and it's a string. You can rely on that. We've made some changes to the way we return dates and date times. So you'll Notice that that's ISO 8601 format. It's more human readable. Now we will return ISO 8601 that long, 2020 01, 10, etc. But we'll accept both the new and the old format for backward compatibility because we know that there are going to be folks who are still reading from the old APIs and writing to the new ones for a while. Then we've got properties. Now, what's a property? Property is basically a field on an object. So you can see here that the properties returned with the contact are email, first name, and last name. And that's new because we're returning default object properties for all objects and this really is meant to align with the in app experience. So if it's a required or suggested field on the object create dialog, we returned it in the response by default. Now, you can of course customize the list of properties to be returned to be whatever you'd like, but from a getting started standpoint, seeing first name, last name, email tells me that this is probably a human, a contact record and not a company or a deal. Okay, cool. So now we can get a single object. What about lists? What changes have been made with lists of results? Well, here you can see we've stuffed the results in a results JSON key that's the same across every list of results that you'll get from the new HubSpot APIs. And we've addressed paging. So if you're familiar with the old way of has more and offset with different casings and different prefixes. This is a new standardized way to deal with it and it uses an after token. And if you're, if you're like me and really appreciate a little hint to help you get started, here's kind of a cheat code. Hey, here's the link to the next page of results. And if you just plug this in, you'll find your way there. Okay, Taking a step back and thinking more systematically about our API design approach, we're really into rest, but we know that it doesn't fit all cases, so we added actions and these are just standardized way of doing performing an action in HubSpot. Again, not everything is a crud operation. So these come in synchronous and asynchronous flavors. Really the reason that they're important is that we build on top of them to create batch operations. Pro tip batch where you can it's way more efficient and we love to see it. Batch extends action. It's a post HTTP operation and the last piece of the path segment there, create is a verb so you know that you're performing an action. And these batch operations should all be consistent, so they'll take a JSON key of inputs, which is an array of the things you're passing in. So I want to create two contacts, one with a first name Alice, another with Bob and I'll get returned a list of results. We've been pretty explicit about the semantics of how batch works. So a create operation, a create batch action works like a single post, right? Or several single posts batched together. And it's just HubSpot handling, handling that multiplicity for you. And of course with batch we need to be able to handle batch errors. So new in the V3 API we're returning 207 multi status responses. So if some things in your batch worked, we'll put them in the results and if others didn't, we'll put them in the errors array so that you know what needs to be retried. Okay, archiving. This is really about the object lifecycle within HubSpot. So an object gets created and it's in an active state and then something can happen that can cause it to be archived. That might be an API operation or someone operating within HubSpot app from archived, it can go back and be restored back to active or it can be purged, which is HubSpot managed. Now you can dig in, we can dig deep on this, but I don't think it's the right use of time right now. Just want to give a paint a high level picture of how we're thinking about the object lifecycle within HubSpot. Okay, errors. This one is I have a love hate relationship because a good error can be very informative and give you very clear next steps, but a bad one can be so incredibly frustrating. You were making great progress and now you've hit a brick wall. So we've designed errors to be very explicit about the data that they return so you'll get a message, a correlation id, a category and some context, which are really just tokens that you can use to inspect what was going on around the error. So while I've got my soapbox here, I wanted to stand up and share some error do's and don'ts do leverage the context tokens. They should tell you a bit more about what's going on in the request and where the error was thrown. Check for sub errors because we can roll up multiple errors into into one HTTP response. Use links included in the errors to learn more, but please do not parse the string error message. It can change. Don't do it. It's not a good idea. Don't automatically retry on 4xx errors because besides 429s. Usually something needs to change on the client side in order for that request to succeed. And don't forget to include the full error on help requests because it can be really helpful for folks in HubSpot trying to chase down what went wrong. So we've just covered a very small amount of the in depth work that we've done to make our APIs more consistent. We thought long and hard about this and discussed it for a long time, going from the very low level about what HTTP methods and response codes and media types are appropriate for which situations, all the way up to high level interaction patterns like event streams, search and drafts and revisions. We've invested a lot here. I'm pretty confident in saying that we didn't get everything exactly right. If there are areas of the API, especially the new ones, that you think could use some love or cause you particular frustration, please give us that feedback on our developer forums. We really, really appreciate that Staying Connected so we talked a lot about what has changed. Let's just quickly review what hasn't so you can know what is solid ground under your feet. So the base URLs API.hubapi.com hasn't changed the way authentication works, the rate limits, the webhook payloads and signatures haven't changed, and the CRM card response payloads haven't changed. And while we're really excited about the work that we've done so far on our new V3 APIs, we know that there is still more work to do. So we are actively working on property audit or property history. So knowing how properties within a CRM object changed over time, returning association IDs in search and batch read, getting a new refreshed engagements API and also contact list lists. This is we're always looking for more feedback, so if you've got ideas again on how you think what other features would be really useful in the HubSpot APIs, drop those in the Community forum and subscribe to our Developer changelog in order to get notified of new releases. So now I'm really excited to turn it back over to Francis to talk about how did we actually get this done. Thanks.

Thanks Chris. While it's great that we're able to accomplish this with HubSpot's V3 API, a one time project is not enough. We need to ensure that our APIs stay consistent over time. To do so, we've introduced a foundational usability framework as well as a set of tools and processes to help make sure that we can deliver on that promise we started by drafting the API Design Guidelines, an evolving resource used by our teams to build awesomely consistent APIs that our developers love. We pair that up with a process called Design Reviews, where we work closely with PMs, engineers and designers to ensure that they're using best practices when building APIs. Next, we built an API catalog. This catalog is powered by Swagger, which makes it possible to automatically create and publish documentation at build time. It also offers teams a way to visually review our entire API. After that, we introduced a linter for automatic consistency enforcements to ensure that teams were following our guidance and API Design Guide standards. Finally, we put into place automatic protections that alert engineers when they're about to make a change that could potentially harm our integrators. By investing in automation, tooling, and process, we're building APIs that by default are consistent, accurate, and built the right way. That's all well and good, but now that we've learned about the internal changes, let's dive into some of the exciting new developments they've made possible. This March, we launched a new developer site. It comes with a lot of horsepower under the hood. The newly redesigned Doc site is powered by Swagger, which makes it possible for users to interact with the API without ever leaving the site. Additionally, we now consistently offer examples in the most popular programming languages for every API. In addition to interacting with the Doc site, developers can now use our client libraries. They make it even easier to interact and work with the HubSpot API. They come prepackaged with standard functionality that covers things like auth, error handling and rate limiting. Check out the client libraries in HubSpot's public repo, or sell them for your next project. Let us know what other libraries you're looking for in the Q and A. And finally, the Doc site now supports downloadable postman collections. This means that developers can now collaborate with teammates and rapidly bring rapidly prototype with the API. Want to see it in action? To access these new Postman collections, go to any Docs page with an available API and click this Run in Postman button. We'll automatically preload all of the APIs grouped by category so that you don't have to you can quickly make calls and get real data back from your portal in seconds. These tools have been available to users for some time now, and the feedback is overwhelmingly positive. My favorite is this email we received from one of our developers. This is fantastic news. So happy for a proper rubygem. A few seconds later they sent oh God, this code is so much friggin cleaner than the gem out there right now. That's what we love to hear. We even got a muscle emoji from one of our beta testers. This is just the beginning. We still have a lot of work ahead of us, but our teams are tirelessly working to bring this same standard of consistency and usability to our entire API. In the coming months, we'll be continuing to roll out our V3 updates we with a sunset date to be determined. But don't worry, we'll give you plenty of time to migrate. Now I'll hand it off to Tricia to talk about the future of the app ecosystem.

Hi everyone. I'm so excited that you're here with us today. As you have already heard, there's so much that we're building and planning for that will make HubSpot the best in class developer platform and a place that you can truly innovate. I'm Tricia Chang, the Group Product Manager for the Ecosystem Product group here at HubSpot, and if you aren't already excited about the investment we're making in our APIs and in our platform, I'm here to talk to you about how we view the ecosystem opportunity and why we continue to be extremely bullish on building a platform and investing in the developer experience. But before we get started, it wouldn't be a presentation without a reminder on forward looking statements. There is information in here about the ecosystem opportunity, but I don't have a crystal ball. So the market and our own plans and roadmaps are subject to change. And with that, let's get started. Over the past decade, the Martech landscape has grown faster than anyone would have predicted. This blistering pace has resulted in over 7,000 unique apps in the martech landscape in 2019, and in April this number hit 8,000. But this year isn't over, and for many reasons, it might look and feel a bit different. Without sugarcoating it, this year has been really tough. From dealing with a global pandemic to navigating big societal issues like racial injustice, we're not quite sure what the impact of these events or movements will have on the end of your landscape just yet, but what we do know is that the opportunity is still there. In these challenging and changing times, we're seeing customers take a hard look at every dollar they're spending, and that includes their tech stacks. They're trying out new ways to reach their audience, to engage with them, to retain their customers. And in fact, we predict that the martech landscape will continue to grow at an even faster rate than before. With change comes new opportunity, and at HubSpot we are embracing this opportunity. We know developers can help maximize efficiency and forge new paths to build strong customer connections. So we are exploring new ways to support our developer audience while also being mindful by building diversity and inclusion programs to make sure that we are truly helping everyone build to their fullest potential on the HubSpot platform. Let's talk a bit more about the opportunity. We're talking $121 billion exchanged in the worldwide martech market last year alone, Zooming into SMB and mid market companies are using a whole lot of SaaS. Hundreds of apps are in play at the average business and it's close to double the number seen in the same study last year. So it's no surprise to see that companies prefer to build their own stack, making best of breed selections for each solution that they need and adopting new ideas as they emerge. The ability to use all of that SaaS seamlessly has never been more important. Unfortunately, it's still not easy. When asked about roadblocks to reaching their martech dreams, one of the top three mentions is integrations. It's consistent across various surveys and populations. Customers find bringing their tech stack together really hard and it can be enough of a pain point to cause a company to switch marketing platforms, which is a huge leap. The three way tie between features, cost and integrations is an unmistakable signal. It's a cry for help and the call to action is clear. Even in a changing landscape, software with better integrations will always win. The opportunity on HubSpot is big and growing. We crossed the 1 million mark for app installs late last year and that momentum continues to build. With over 73,000 customers of our software and nearly half a million weekly users of our free tools, it's a broad user base to address and each customer installs an average of six apps, a number that also continues to grow and we are the CRM of choice for startups. These growing businesses are choosing us as their platform on which to build their foundation. HubSpot sees our ecosystem as a huge factor in making our customers successful in our mission to help millions of organizations grow better. Some of you have seen this mspot format before. It's part of our annual planning and how we capture and track our top level metrics. The ecosystem is front and and center. Engagement with integrations correlates with success and we are committed to driving that engagement. We are deeply committed to being an open platform. We seek to provide a level playing field to provide innovative high value solutions to our joint customers and the ability to build those solutions on a high quality, complete and consistent API. Being a platform company means being judged not only by our own success, but on the success that we enable. This quote from Satya is among our team's favorites. We will only be long term successful if people are making more money around us. It's not enough just to open the doors. We need to welcome you in. We're investing in growing and engaging our community. From our developer relations and support teams, to our community forums, to our dedicated developer NPS tracking, to our changelog and our newsletter, we want to build a platform where you can feel like the hero, where you can enable anything. Building on the HubSpot platform helps you win and it helps your customers win. So thank you for being a part of our developer community and for joining us today.

All right, so I would love to ask our presenters to please reveal yourselves and turn on your mic so we can all see and hear you. Awesome. And I would love to thank our extremely engaged audience for asking so many amazing questions. Unfortunately, I don't think we're gonna have quite enough time to get through all of them today, but we're gonna do our very best to address as many as we can. We did receive one question in advance and I appreciate all of you dropping in your questions today. But before we jump into that, I would love to just take a moment and introduce you to the folks all the over on the call today. I'll call on each of you just to introduce yourselves and we'll start with Chris Baldoff.

Hey. I'm an engineer on the developer experience team at HubSpot and I've been here for about two and a half years.

Awesome. Thanks, Chris. How about you now, Tricia?

Hi, everyone, I'm Tricia.

I am the group product manager for the ecosystem Product group. I joined HubSpot almost a year and a half ago now. So, so excited to be here. Thanks for tuning in, everyone.

Thank you so much, Tricia. We have two Zachs on the call. I will nominate Zach Wolfe to go first.

Everybody, my name is Zach Wolfson. I'm on the developer relations team. I've been at HubSpot for about six and a half years here. So very excited to get moving on some of these new APIs for you.

I'm sorry I called you Zach Wolf. I'm so used to calling you Wolf that I forgot the sun. How about you, Zach Robbins? Yeah, I'm the other Zach. My name is Zach Robbins.

I lead the API tooling team here at HubSpot.

I've been here for three years. All right, so how about you, Francis?

Hi everyone, I'm Francis, I work with Zach on the API tooling team.

I've been at HubSpot for a little.

Over four years now.

Awesome, thank you. Finally, I will introduce myself. I'm sj, stands for Sarah Jane and I lead our developer community initiatives at HubSpot and I'm super excited to have all of you here today. All right, so without further ado, let's dive in. I did mention we had a pre submitted question, so we'll just drop into that one first and this one's going to go to Zach Wolfson. How do I import relational data into HubSpot?

Yeah, so the best way to do this here for an initial import is to use the import a CSV function here. So this is a great way to get all your objects in, even if you can't store the HubSpot ID on your system, because I know some systems are limited in that way. So you can import a couple of CSVs, have them related to one another. It's basically an exact replica of what you would do in a ui, but now you can do it programmatically. So if you need a nightly update, it's perfect for that. As a fallback, you can always use the basic CRM APIs and the association APIs to handle things if you need a little bit more custom logic. But overall the CRM import API is what you're looking for.

Fantastic. What we're going to do now is move into my best attempt to package up some of the questions that came in. There were several questions that came in about some of the sort of backward filling approach to API to our V3 APIs. So I'll just kick off with one of them. This one was from Dan Roman and I'll hand this over to you, Francis. Will the updates being made to the HubSpot API be backwards compatible with existing integrations?

Yeah, that's a great question.

And the short answer is no, since a lot of the work that we did to make the API more consistent changed kind of the way it was built.

The APIs won't be backwards compatible.

But to couple that answer with some of the other questions around Timeline as a lot of these API groups, so cms, CRM, move out of beta and into ga, we'll be giving folks plenty of time to migrate over to these new versions of the API. And we're doing some work to help provide a resource that can help you see the entire landscape of HubSpot's available API soon.

All right, let me just see if there was. I think there might have been a couple of other similar questions I think that should have addressed it. So I'm going to move on to a question for Zach Wolfson. Can we get all contacts with a single call?

Good question, very tempting, but the answer is no. People can store lots and lots of contacts in their CRM up to, I believe 15 million is our kind of top limit there. So that's just too much data to include in a single HTTP response. So we do implement scrolling here. So it will take a couple of calls, but the changes we made in V3 should make that scrolling much easier. But no, you cannot get it in a single call.

Okay, great. So I think that answered a couple of other folks questions as well. There were some similar ones that came in. Let's go over to. And I apologize if I end up going back to similar topics, but I'm just trying to follow the order of the questions, you know, they were asked in random order, so bear with me. So, Chris Baldoff, would love for you to ask this question. Answer this question from Jacob. Have you considered adding API examples for JS other than node like jQuery?

Yeah, and I'll address sort of the full range of questions about language examples and SDKs. We were open to adding more languages and examples SDKs as folks find them useful. I saw a lot of talk about a C or Net SDK and I created a community forum post that I just put in the chat. If you want to go and upvote that, that's the best thing that you can do to give us a signal that that's what you're looking for. In general, just so this isn't specifically about jQuery or any particular language, but I do want to say we are in a good position to leverage the investment that we've made in our API consistency and our API tooling to be able to fairly quickly, when the interest is there, investigate and be able to develop these things as the use cases warrant.

All right, thank you, Chris. And to folks who are raising their hands, we would love it if you could submit your questions directly in the Q and A panel. And like I said, if we don't get to them today, we will be sure to answer them after this this call, but there's a good chance we'll be able to address them today. So the next question is going to be for Zach Wolfson, another one for you, and this one's a little long. Let's see if I can try to synthesize it here. I've seen a lot of bizarre race conditions both in my own coding and in other issue reports on the Dev Slack API channel. And that's by the way, a shout out to everyone. We do have a Developer Slack community, so we'll share out all of those resources and you can connect with your fellow developers there to talk about APIs, CMS, all kinds of good stuff. In any case, I'll go back to the question, I'll reread it from the top. I have seen a lot of bizarre race conditions both in my own coding and in other issue reports on the Dev Slack API channel, where the search claims that an object is not present when it actually is present due to indexing delays. This causes challenges in making sure you do not have a duplicate of an object, like a contact or company. There's a legacy create or update for contacts, but nothing for companies. Can we get more clarity on the indexing behavior of how to avoid making duplicates since the API doesn't offer duplicate protection like the GUI does?

Yeah, great question here. So I think there's actually kind of two questions embedded in this one question. So the first is the behavior of the search API, and right now the way it's designed is it's best suited for answering one off or ad hoc questions. Hey, I just want to get a How many contacts have the first name of Zach on this call? We get two back and it's great. It doesn't change all that frequently, so it's perfect for answering that type of a question. What is not so great at is scrolling over long periods of time. So when we get into those portals that have millions of instances of an object here, there are some delays here. The team is looking into what it would take to implement a more robust scrolling API to more efficiently support that use case. So we're definitely looking into that. We've heard you on that. And the second is a create or update logic here. So we're looking into what that might look like for different objects. Contacts Email is a fairly obvious identifier that we've supported for a while. I think we'd like to continue that in V3, looking at how we want to go about that for other objects. There's still a debate internally on how we want to handle it, or if that's even the job of the API, if it should be something that's handled in the client libraries that we produce. Definitely want to hear some thoughts on that on the Ideas forum that's@ideas.HubSpot.com but we're definitely looking into how we can handle that for you.

Thank you. Zach. This one's for you. Tricia. A question from Daniel Gomez. Basically asking about API usage limits and how they've been impacted by V3 APIs. Specifically, he's asking that he would like to get a boost on the 10 second rolling limit.

I love this question.

Thank you for asking it. I mean, the API limits is something that we know impacts developer experience across a lot of different use cases. And so if you've been on our platform for a couple years, you know that we actually updated our limits last year, showing our commitment to always revisiting and figuring out whether or not our current rate limits are able to like satisfy this. And so similar to kind of how Chris asked or you know, the plugged the community forum similar thing. I would love to hear. I'm a product manager, so obviously I would love to hear your use cases and reasonings for needing higher burst limits. We know that it is something that is asked for and so would love to continue that conversation and really dive into finding a limit that is appropriate for what you guys need it to be and for our business as well. So really excited about that one.

Thanks. Tricia. Francis, this one's for you. V3 APIs. Does this extend to the CMS Hub as well?

Yes.

So with the new setup on the Developer Doc site, you'll see a form on all the pages where we're currently working on V3 upgrades for specific APIs. So I saw a couple questions about specific ones. We are planning on extending that out to CMS Hub. So hubdb, blogs pages, those are all in the works. And once they're ready for beta, we'll be announcing those and releasing them live on the Doc site.

Fantastic. Okay, let's see here. We've got so many questions. Let me just choose the next one that's going to be as helpful to as many folks as possible. Just one second. We got so many votes for different SDKs. That's super helpful information for us. Thank you. Here's a question from Steve. Steve Minor, very interested to learn about your plans for field validation. One of our most challenging data cleanliness integration challenges is the inability to check user entered data at the create and edit time. Does anyone want to take that one for field validation questions or is this a little bit less API focused?

Yeah, that's interesting. I hadn't thought about that deeply. Thank you for raising it. The question that comes into my head, are we talking about custom fields or are we talking about HubSpot provided fields? If we're talking about custom fields, which sounds like it makes the most sense, I think that's something that is worth bringing back to the product team to.

Talk to them about.

Looking into that feature. And we'll take care of that as an output of this conversation.

Thank you so much. There are a couple of questions around timelines for the V2 API moving to and when everything's going to be moved to V3. I know we don't have an official sort of word on that yet, but if anyone wanted to jump in and give folks just a general idea of what we're thinking there.

Yeah, I can jump in here. So, in terms of timeline, again, we're going through this big process of leveling up our entire existing API, so we won't be deprecating the existing version until we've finished going through the V3 process with our existing endpoints. So between now and when we've released all the V3 versions, we'll be announcing a sunset date and we'll make sure that folks have plenty of time and plenty of notice to migrate off of the previous versions and onto the new versions.

Thank you. Okay, so there are actually a couple of questions about just general best practices on ways to keep integrations in sync. Specifically, there's one from David asking about basically a problem that he's had in integrations. As an integration modifies an object via API and then the workflow says that the object has been modified, it would try to send the change back to the system that actually originated the change, and so forth. And then he asks, can you please elaborate on the best ways to keep integrations in sync?

Yeah, I think I'll take this one here. So it sounds like what we've got going is an external integration triggered a subscription to webhook, that's saying, hey, I have a new change, when in fact it was that same system that caused the change. This is where the probably the right way to handle this is to get the web hooks, take them in batches, and then ask HubSpot via the batch, get APIs for the current state of the world for that set of objects, and you can compare it to what you have stored in your database so you're not constantly updating and overriding yourself. If the data matches, no updates are required. Otherwise you can take the most recent data that HubSpot has. That way you can break that cycle of a circular dependency Here. It does require an additional API call, but because you can batch getby IDs, it shouldn't be too much overhead in terms of your API call limit.

All right, can someone talk a little bit about batching, workflow, extensions, webhooks, data? Vlad had a question about that. Basically saying that there are, there's sometimes poor performance on a million plus contacts, for example, if anyone wants to jump in about web hooks.

I think that's something I'm gonna have to defer and go back and talk to the product manager of the automation team here. I know performance is definitely something we're always concerned about and having good experience for you. So let me get back on a better answer for you.

Here's an interesting question from Reg. Slightly less programming focused and I know that a lot of folks that leverage our APIs are not necessarily identifying as programmers, so I'll read Greg's question and see if anyone has any insights. So Greg says that we're moving from Salesforce to a CRM that's not supported by HubSpot natively, but we are thinking of using Pysync to suck all of the data out of Salesforce via HubSpot and then Resync it to the new system. Is this feasible or should we look into a new approach? And then Greg says, I'm not a programmer, so coding something from scratch, as our examples are here today, is not really an option for them. Any PI sync aficionados in the room? If not, we can definitely connect you with someone and get you the answer to this question. All right, cool. What we'll do, Greg, is we'll reach out one on one and make sure that you're connected with the right folks at HubSpot to give you best practices around this one. All right, I'm scrolling through lots of SDK questions. There's lots of like forward looking questions. I wanted to see if there was anyone in our panelist group if there's any specific questions that you spotted that I didn't that you would like to answer. If not, we can move on to the next couple closing slides.

Chris, I just saw one about GraphQL. I wanted to say say something there. As I said, with the previous SDK examples, knowing use cases of exactly what customers want to do with GraphQL really helps us get in tune with what folks are looking for and couple that with. I think there are some internal hurdles that we need to meet before we so we have experimented with GraphQL internally. We are aware of what it is. I think there are some internal hurdles that we need to meet to make sure that the system is secure enough, reliable enough, performant enough, usable enough before we were to take a serious look at making that widely available.

All right, thanks, Chris. Anyone else? Alrighty. Again, thank you so much to everyone for your great questions and for joining us today. I wanted to make sure that you're aware of all of our different resources. So if some hubspotters can jump into the chat and let folks know. Our main website is developers.HubSpot.com if you could also drop a link to our API forums, that would be super helpful. Those are two great places to get in touch with us and get answers to your questions and find your way through our docs if there's any more specific questions. Again, we're going to make sure that everyone on today's call and all the questions that you asked will be answered, so don't worry about that. And we're going to be sharing the recording and the slide deck for this presentation on our developer blog@developers.HubSpot.com blog very soon. And I think Micah might have dropped in the developer newsletter sign up link a little while back. Maybe you can drop that in one more time, Micah. And without further ado, I would love it if everyone could take just 30 seconds to one minute of their time to fill out a very brief survey about this event. It really shouldn't take you too, too long. That's at Bit ly Julyapi. It rhymes, it's easy to remember, but it is case sensitive. So please make sure you use capital J and capital API in July API. That will get you straight to a very, very brief survey where we can gather your feedback and create more events like this. That that will be helpful for you and we are really looking forward to rolling out more connection points with our community with you. If you have any ideas, more specific targeted events that you'd like us to do, please please include that in the, in the survey and that would be super, super helpful. And again, we appreciate you so much. We're gonna give you a couple minutes back. I know for us over here on east coast it's almost lunchtime, so I know there's all kinds of different time zones here. So again thank you for joining from wherever you're joining from. We really appreciate it and we'll be getting in touch with you and sharing the recording shortly. Thanks everyone.