How to Help Businesses Scale with HubSpot: A Developer’s Perspective

Welcome to how to Help businesses scale with HubSpot developers perspective. My name is Dennis Edson. I'm a developer advocate@HubSpot and my pronouns are he, him. For my visually impaired friends, I'm a balding white guy with most of my hair located below my scalp and it's almost like I'm being compensated for the lack of hair here.

But whatever.

I am wearing a green shirt and I'm in my home office in Beacon, New York. And before I turn over the virtual mic, I want to take care of a few housekeeping items. One, this is being recorded. You don't have to ask. It is. I promise you'll be able to access this recording here and on the YouTube after the event. Two, be nice. We want your opinions good and bad, but please just come on, be nice. And three, the most important one, ask questions.

It's kind of the whole point of.

This being live thing, right? So don't worry if you think it's a noob question. If you don't know the answer to something, I bet you five bucks out there there's someone else who has the same question or didn't have that question, but does now. So guess what? You ask the question, you help a friend, so do it. All right, I'm going to be hanging out into the chat, so if you have questions, I'll try to collect them all. And we have a Q and A session at the end of this and I will pepper the smart folks here to answer them. Let's see if they can do it. Speaking of the smart people, you may have noticed some other people on this feed. I'm going to turn it over to Hannah and she is going to take over. Go get them.

Thanks. Thanks Dennis. So as Dennis mentioned, my name is Hannah, my pronouns are she and her. I have brown hair and glasses and I'm at my home office in Cleveland, Ohio. I'm also a developer advocate here at HubSpot. I focus mostly on our CRM and our APIs. And today joining us are Sequence co founders Eric and Anthony and we're going to be discussing how developers can help HubSpot businesses scale their CRM. As you know, scaling is a huge problem for businesses. Integrations can break down face several problems such as rate limit issues, consistency issues or just difficulties with custom objects. Properties, associations. This constrain a system and make it really difficult for businesses to use their CRM. But we've got good news. There are ways to approach these issues to help your integration avoid these problems. For example, you can build efficiency in your integration by caching data and simplifying queries. But first, before we get into all that, Eric and Anthony, let's take a moment and if you would just introduce yourself, your roles and a little bit about yourselves.

Thanks, Anna. I'm Anthony. I'm the co founder of Sequin, and before starting Sequin, I was a director of engineering at if this, then that the API platform. And I saw firsthand what it takes to build and scale hundreds of API integrations. And I started Sequin with Eric a couple years ago to make integrating easy for developers.

Hey everyone, I'm Eric, the other co founder of Sequin, and before Sequin, I was the head of product at Zephyr, where I oversaw one of the largest integrations with YouTube. We did about 8 billion API calls a day, so just kind of a new magnitude of scale. And now at Sequin, we've been able to work with tons of companies of all sizes building on the HubSpot API. And we're just really excited to share what we've learned as we see different businesses hit different challenges as they build on top of HubSpot.

Thank you. Thank you both. So now, before we dive into the questions in today's primary webinar topics, I want to set the stage for both of you and for our viewers and just introduce some basic HubSpot components that you two are going to be explaining in much greater detail. So I'm going to share my screen real quick. Give me one moment. There we go. Okay, can everyone see my screen? Alrighty. So as we mentioned, so we've already introduced these two folks, but first, what I want to start with is what is a CRM? Let's say that you're a developer. You've been tasked to help build an integration with the CRM for a business. The CRM is a customer relationship management platform. It's designed to help businesses manage their interactions with customers, prospects and leads. As a developer, understanding these key components and features of the CRM are going to allow you to build those integrations, customize functionality, and leverage its capabilities so you can enhance business processes. Then next we've got our APIs. So HubSpot offers several APIs. And these are a set of services that allow the developers to interact with the platform programmatically. The APIs enable developers to retrieve, manipulate and update Data within the HubSpot CRM. It also allows you to integrate with HubSpot and with other external systems and applications. And then with those APIs, we provide a way to interact with various objects and their associated data stored in the CRM Start over objects in HubSpot are categorized into two different categories such as your standard objects which are your contacts, your company deal, tickets, calls, and then you've got your custom objects which is self explanatory in the sense that it's an object that you can create based on anything that you need within your business. Could be a car, it could be a pet, something of that sort. Each object has its own API endpoints that developers can use to perform specific actions. Each of those objects has an object definition which includes its properties and results in instance of an object. For example, you can use the Contact API endpoint to fetch specific contact info or company API endpoint to to retrieve company details. And then lastly associations. HubSpot APIs allow you to establish relationships between different objects within the CRM. So for example, you can associate a contact with a company by linking them together using their unique identifiers. This association enables you to maintain connections between related objects and access them seamlessly through the APIs. Then finally you can look at my horrible handwriting and I apologize, but I wanted to draw a diagram that ties all these concepts together. As I mentioned, the associations allow you to establish connections and link related objects together. This enables a comprehensive and interconnected view of your data. Each object has a unique ID that distinguishes it from other objects. Within this diagram you can see that there's an object instance which would be a contact record representing myself Hannah. And then you can see how the objects are associated with the contact and company. So I'm a contact from the company HubSpot. But you can also see how you might add an association label such as developer advocate which is my role and how it ties the relationship between myself, the contact and the company HubSpot. And then lastly you can see there's activities or engagements and events that are also connected with associations. Like I said, the reason I'm showing you this is because I just wanted to give you all just high level overview and introduce these terms and the CRM objects to help you follow along with today's webinar. As a developer, when you're building integrations with the CRM, your goal is to help those business manage these aspects of the CRM so they can run their business effectively. Now stop sharing. Now we're going to. So Anthony and Eric are gonna help us better understand how we can set ourselves up for success as a business grows with the CRM. So to kick it off, Anthony, what would you say are the key considerations for partners building integration with The CRM to ensure that the API integrations can scale effectively with customers. How can we design an API integration with scalability mind and just ensure that they can handle increased traffic rate limits, high data volumes as a business grows?

Yeah, this is a deep topic. I think it's worth starting with just talking about some of the challenges that typically developers face as they scale these integrations. Integrations tend to get exponentially more complicated as the data moving back and forth grows. So if you start off with 100,000 objects in HubSpot, your integration might start off pretty simple. But then when that grows to a million or 10 million objects in HubSpot, your integration, you might get or need to be 10 times more sophisticated. And there are really two primary reasons for this. The first is that your queries are going to get more complicated and your result sets are going to get bigger. So, for example, let's say you need to find all the users or customers that place an order for a given product in order to send them an email. HubSpot has a very expressive search API, but for more complicated queries like this, you're still going to have to make subsequent requests to sort of gather all the data that you need across the different objects, and then you might end up needing to paginate the results as well. So HubSpot is going to return, depending on the endpoint, anywhere from 100 to 200 records per request. And that means your code might need to paginate if you have thousands of customers that match whatever search parameters you're using. So complexity begins to emerge. The second big challenge that comes up as you're moving more data back and forth are those rate limits. And so HubSpot's API, like other APIs, has a rate limit. It's pretty generous. That API rate limit specifies how many requests you can make per second. And the main reason these rate limits exist is to prevent misuse and make sure that everyone, you know, all customers, can kind of get equal service and availability from HubSpot's API. At a certain point, HubSpot's expecting you to do some optimization to make sure that you're not constantly hammering them to ask for data and you're coming through at a reasonable volume. And so we can talk more about what those strategies are next.

That's great. And I guess when it does come to simplifying those queries and the performance. I see Carter has already mentioned GraphQL. Maybe you could provide a specific use case or an example in which GraphQL really helped out.

Yeah. So GraphQL is supported on HubSpot's CMS part of the API. And what's really nice about GraphQL is you can specify exactly. You can do joins between objects pretty easily, so specifying posts and authors and getting back all that data. And you can tell HubSpot exactly what properties that you want when making those requests. That CMS GraphQL API is really meant to power a front end of an application and can be pretty effective at doing that. The for objects and custom objects, your best bet is the search API for trying to do expressive sorting, filtering, et cetera. And for that endpoint too, you can specify exactly what properties you want to receive. So oftentimes you'll have objects in HubSpot that have 200, 300 properties on them. And if you're requesting all properties in every single request, that can make your request a megabyte, two megabytes in size, which can take some time to transfer. But if you only need 10 properties, specify that in the request, either in GraphQL or via the search endpoint, you can bring those request sizes down to 50, 100 kilobytes. That'll just move a lot faster and also just be less work for your JSON parser to decode.

That's a good point. And then I guess also when it comes to caching data as well, do you have any tips or suggestions about that for developers?

Yeah, so caching is a very critical. It's going to become very critical if rate limits are an issue. And really with caching, there's three like when you're starting to cache data, you then have to deal with cache invalidation. Famously, in programming there's two hard parts. One is naming things, which I'm terrible at and I will not try to give advice on. The second is cache invalidation, which I'm decent at, and the three main cache strategies that folks use. The first one is just a simple time to live. You might say, okay, I'm going to grab this customer object from HubSpot if I don't have it, if there's a cache miss, and then put a six hour time to live on it. And then when that expires, you just have to refetch it whenever someone requests that object. Time to live. It's very easy and it can work pretty well, but sometimes it's just too slow for your needs. So if an operator over on HubSpot updates that customer changes the email, your application is not going to reflect that, and that can be problematic. So the next strategy that you can use with HubSpot is webhooks. So you cache some data. You then rely on webhooks to tell you when that data is no longer valid, which is the key part here. And webhooks are pretty good. You can use webhooks with all standard objects. HubSpot doesn't have webhooks for custom objects or for associations, so keep that in mind. The main challenge with webhooks is if you're down or you miss the webhook, you're kind of hosed. There's no way for you to know that that cache should be invalidated. So I usually recommend, if you are using webhooks to still set a TTL on your cache, otherwise you might have stale data that you're hanging on to indefinitely. But webhooks can be a very nice and efficient way to invalidate any kind of local cache that you have. The third option, which I think is the most robust, it's what we do, and we see a lot of big integrations do, is to set up polling to figure out when things have become stale. So you might have a cache of customers or custom objects locally, and then you can periodically pull HubSpot and use the search endpoint to ask HubSpot, hey, what has changed since the last time I contacted you? HubSpot will return that data back to you, and then you can invalidate the caches and optimistically refresh the caches for everything that you're caching locally.

No, that's great advice, I guess. Also, when it comes to improving the performance and the scalability. You mentioned associations, and I want to touch on using the batch endpoint for the associations API and how that can be really helpful as well, especially with pagination, like you mentioned before, could you explain a little bit more detail about how that's really helped you and your team?

Definitely. So associations are. They're relatively new to HubSpot, as I understand it, very powerful. You can, as Hannah was mentioning, you can associate any two objects in HubSpot to each other and you can give them a label. So you can have two objects associated in multiple ways to each other. So very rich and kind of maps very well to businesses in the real world. The challenge is that associations aren't yet supported by webhooks, as I said, or by the search endpoint. So finding out if you're doing any sort of caching on associations or you have a complex query you want to make about associations can be a little bit more challenging. But There is a couple strategies you can use. One of them, as Hannah mentioned, is the batch associations endpoint. And, and you get back, I believe it's 1,000 associations per request, so it's a pretty high volume. Endpoint associations themselves tend to be pretty small objects, so you can fit a lot into a response and you can paginate through any given associations between two objects fairly easily. So if you need to do a query that involves a complex filtering and sorting between all the associations between two objects, it is feasible oftentimes to make multiple requests to grab the whole list of them and then perform that filtering or sorting on the application side. The second option that you have for all endpoints, for search and for the standard read endpoints, and even the batch read endpoints, is you can ask for associations to be included. So if you know that you want to grab all the associations between a customer and a company, or let's say that you want to do a filter where, you know, give me all the companies that have over a million dollars in revenue and also give me all the products associated with them. You can make a query like that by asking for the companies setting on those filters and then asking for the products to come back in the association. That's your best bet for working with those associations.

Awesome. Thank you. Then when it does come to monitoring performance of everything, do you have any optimization strategies? Are there any metrics that developers should make sure that they're tracking just to ensure that everything is working efficiently?

Yeah, when I think about monitoring, I think a lot about you. You want to know your request volume today, if it's going, if it's fast enough. And then you also want to think about maybe how to optimize. So Perhaps you're at 80% of your rate limit or you might be, you're not even sure and you want to find out is this going to scale, is this happening? And so you know, we personally or Sequen, we use STATSD for a lot of our monitoring. It's an open source tool. It's well supported by a bunch of different monitoring services. And with that you can track the API requests you're making, where it originated and how long it took. So I can give you an idea of how many requests you're sending and who's responsible for those requests. You can also track the time those requests are taking. If your servers are in the US they should probably be taking about 200 to 300 milliseconds round trip to HubSpot. So that's kind of what I recommend. On the monitoring side, another cool feature is that HubSpot will tell you in its responses how much rate limit you have left. I believe the endpoint or the header is called like X HubSpot. Yeah, X HubSpot rate limit remaining. And so you can just take that response header and just throw it somewhere. Like if you're trying to figure out what your baseline is, throw it in a text file or log it out, or throw it in a database. And over the course of a day, you can have a good sample of what your rate limit looks like. StatsD can tell you from your perspective what your rate limit was in a given time, but obviously HubSpot telling you what it saw is even more accurate. From that, you can begin to extrapolate how close you are to the ceiling or whether or not there's any optimization.

You should be doing that makes sense.

Because I feel like developers definitely having that visualization is going to give you a better idea of how you can handle all of that increased traffic in the data volume. Then also, one thing I wanted to know is when it comes to designing an API integration, do you have any architectural components or anything that, that you would suggest developers keep in mind? And I know that Eric will actually be sharing a couple of different use cases about that later throughout this webinar. But as far as strategizing that design, do you have any tips or any key aspects that developers should really keep in mind?

Yeah, so I'll throw a few sort of loosely related things out there. So one of them is it's so often the case that the 8020 rule applies where there's like 20% of your requests that are taking up 80% of the rate limit. And sometimes when developers start optimizing their integration, they end up just trying to cache and batch everything. And that can be fine, but that's just adding more complexity. So if you can use the monitoring strategies we talked about, figure out what that 20% is that's doing most of it, and just focus on those. At first it can keep things a little bit simpler because now you're only having to worry about batching or doing cache invalidation around the really critical parts that are causing a lot of that. So we haven't talked a lot about batching yet, but every object in HubSpot can be batched and you can batch both on read and on write with, which is very cool. So if you want to do an insert, update or delete, you can make a request that has 100 different modifications to make to HubSpot and not only is this more efficient than doing 100 round trips, but it also means you're only using one rate limit token or whatever per request. One tip is just if you want, just start, do all of your interrupting deletes. Just use the batch endpoint, even if you're only doing one thing. Because then later, if you want to add more, it's super easy. You don't have to change your code. So it costs the same amount to do the batch version versus the regular version. And then if your application is write heavy to HubSpot, we've talked about cache heavy being cache heavy on the read side for write heavy. What we'll sometimes will see developers do is basically batch up requests they want to send to HubSpot. So maybe you're tracking usage data. So whenever customers do certain things in your application, they reach certain milestones in onboarding or whatever it is, you're pushing that data to HubSpot. So then your sales team can see the qualified leads. Instead of pushing data every single time the customer does something, you can add that to your local database and then have a batch job that runs that then grabs all that usage data and pushes it HubSpot in batches. That could cut your, you know, API request. On my 100x, the last thing I'll consider, which is kind of related, is audit. You know, auditing where your API requests are coming from and asking yourself, is this my system that's doing this or is it this triggered by a customer activity? So if it's your system that's firing off API requests, it's usually very predictable. Maybe you have a cron job that runs every hour. Cool. This will fire 24 times a day. Not a big deal. But if it's like every time one of your customers loads a dashboard, you're firing off 10 requests to HubSpot. You know, be careful because that could mean that one customer completely locks up HubSpot by taking over, you know, the entire rate limit. And so having some sort of, you know, that's a good area where you might want to do caching or batching to basically sort of debounce or protect HubSpot from, you know, a user to furiously refreshing their dashboard.

Those are great tips. And I see we've got some question about behavioral events or customer contact events. I don't. All right, well, I guess the behavioral.

I think Eric's going to. Actually we have a case study coming up and Eric will talk about how a team that we worked with managed behavioral events, which can be very High volume. So we'll have a cool example for that.

Yeah. And maybe it's a good time to transition into that, I guess. Eric, we're going to be sharing two different use cases. These are two clients of Sequin. We've got Trellis Law and Fin Auto. And so what I would love you to do is just share the two different use cases for each and then maybe you can just walk us through how Sequin was able to support them, what was different about them and maybe just if there's things you would have done differently or just things that you were able to learn from both of these clients.

Yeah. Thank you, Hannah. So let's add some examples to the high level conversation we're having about how you're going to scale an integration. So we can start with one of our customers, Trellis. And they're a fantastic company if you haven't heard of them. They are an AI platform that help lawyers search all of the case law for their state. And the way that they go to market with HubSpot powering it is they really want their sales team to reach out to lawyers after they've started using the product. And they allow each lawyer and each law firm to basically self qualify based off of how many searches they're running, what they're doing in the product and how it's working. And so their sales team is completely blind to who's qualified if data from the application isn't getting piped into Salesforce or into HubSpot. And what they built is a really simple, I'll share my screen here. They built a really simple architecture to do this in the beginning, right? Lawyer comes in, logs into Trellis and then every hour or so they would pipe. These aren't really behavioral events. They pipe very high level wrap ups of what those customers are doing into HubSpot, both into HubSpot contacts and companies. And in the beginning of the company, this is working just fine. They were using the batch API actually the query probably looks something like this and you've all probably hopefully a lot of you on the stream have kind of seen, seen this really straightforward. They're going to take all the companies, update all these properties on the companies and just do it in a big batch every hour or so. And this was working great. And then they began to get a lot of lawyers coming in and what began to happen is every hour they begin to see some rate limits get hit. And this was pretty easy for them to deal with just by beginning to kind of queue up the requests. But what they began to see is that by the end of the day, they had burned through so much of the rate limit that when they were trying to update all the companies, a whole, a whole chunk of the companies just weren't getting updated. Basically the entire tail end just wouldn't get an update because they had exhausted their rate limits. So by the end of the day, the sales team was kind of like twiddling their thumbs. They had a couple options here to begin to fix this. One is they were being relatively inefficient, right? They set up a very simple method for doing this and they were just basically firing and forgetting they were updating every company regardless of whether or not it needed to be refreshed. So they were. They could have gone down the path of basically logging on each company. When was the last time we updated them? And if the company was now due for an update, just update those companies that needed a fresh update. The other option they had through the API was really to begin building some sort of cache, right? Checking in with what was the state of the data in HubSpot, and if the company now needed to be updated, make that update call. But this would require them to basically read, start reading before they wrote, and it was going to be equally inefficient for them. So they started looking to their options to start building that cache. And as we've kind of talked about, there's. They could set up the polling, they could set up just a standard ttl, or they could start looking at webhooks. But each of those lifts were relatively complicated, and they did want the data to ultimately live close to home so that they could run these updates really quickly. So the implementation they began to pursue with Sequen is we provide the cache for them, right? We just pipe all that data, all the contact data, all the company data right into their database every time they run the refresh. They can now quickly query their database to see if the company has or requires an update. And it dramatically reduced all of their batch API calls so that now they can actually update HubSpot even more frequently. Their sales team can get richer and more complete information. And importantly, they can do it really quickly. They can change what data they're sending to HubSpot at any time, and they don't have to really think twice as to whether or not the data has been cached or not, which really kind of simplifies the architecture. So this is kind of going to Carter McKay's questions about is this event data? This is really kind of these roll up Sales qualified data that can really only come from your users and your product database and making sure that it gets into HubSpot so the sales team can work with it right away as well. So that's trellis. Let's look at another example here, which is Fin Auto. Fin is another just awesome company out of Germany. I know we have some German folks coming in on the line, so maybe you've heard of Fin, but if you haven't, Fin replaces buying and leasing a car with a car subscription. And they manage all of those subscriptions in HubSpot. It's contacts, deals and a couple custom objects and it manages their entire fleet of vehicles. Now internationally, it's really wild. And the benefit of Fin is instead of buying or leasing, you basically get to subscribe to a car. They take care of all the insurance, they take care of all the maintenance and it just shows up at your door. So as I mentioned, they do all of this in HubSpot. So when someone comes in to subscribe to a new car, their servers basically immediately add a contact, a deal and a car and combine it together with associations. The car being what Hannah mentioned earlier, a custom object. And that creates the subscription object. And what's important to understand here is the customer in the web app is waiting for those HubSpot objects to be created to actually complete their checkout. So the lag time in the API is really important to Finato. And the second thing is anytime the customer goes in to check the status of their subscription, so if they want to see where is my car or what were the terms of my deal, that's also going to live, check against HubSpot. So if Anthony mentioned this use case earlier, but if someone's coming in to that web app and it's constantly refreshing to see like where's my car, where's my car, where's my car? That can quickly just burn through several hundred API calls because it's a multi object request. So they were facing kind of two big problems here, which is one, they needed to really dramatically reduce and speed up their reads. So they wanted a local cache, so, so that if a customer did come to check on the SaaS of their car subscription, they would load instantly in the web app. And that meant that they did need to pursue some sort of local caching strategy. And the second thing is when they were going to be creating a subscription, they needed to make sure that they kind of batched and queued the creation of those new objects. Otherwise if they were in a really facing a really good business problem, which is 10 customers want to create, create a subscription, all at the exact same 10 second interval. One of those users would basically just be out of luck. So they also were going to go down the path of basically setting up their own cache, building their own queuing system. So when they were going to make those writes, making sure that they kind of batched them together as best as possible and they were going to pursue the exact same strategies that Anthony had mentioned. They wanted to use webhooks. Webhooks will be coming to custom objects in the Future, I hope, HubSpot team. But they needed to start getting some sort of cache in place. What they did with Sequin was we just built the cache for them. All their custom objects, all their associations, and then all those standard objects, deals and contacts are in a local database. It lives right next to their web app. It means that all their customers can get that data incredibly quickly. And the process of queuing, batching, dealing with the rate limit is completely abstracted away from the concerns of the web app itself. The other thing that I'll mention here, which was a really cool use case for them, is once their HubSpot data was this close to their web app, they're able to use that HubSpot data throughout their organization. They've built other internal tools. Like you can imagine that they're managing a ton of HubSpot tickets and requests and they're able to queue that all into all sorts of other internal tools to run their business. So these are a couple practical use cases of companies that are using HubSpot in really cool ways and to really tie that business logic into HubSpot and their web app and really make it work really nicely using caching and some of these scaling tools. So those are some examples and if you'd like, I can show you a quick demo of how it works.

Yeah, let's do it. I think everyone would love to see that.

Okay, so we'll give you just a quick demo of how sequence works in this ecosystem then, please. As you see all this, these use cases would love to see some cool questions come in. You guys should be seeing my screen right now. Let me just explain what you're looking at here. On the left is Sequen, on the right is a terminal just plugged into a database that's syncing. We have a HubSpot sync set up here. I'm not going to walk you through the process of sync setting up a HubSpot sync with sequin because you probably all have gone through the HubSpot OAuth flow before. It's basically just that we got some companies and contacts syncing to a database and this is connected to just an empty HubSpot developer account. Completely empty. There's nothing in here. In fact, if I do a quick select count star from HubSpot contact, you'll see this is also completely zeroed out. The database is acting as a cache and it's syncing directly to this HubSpot instance. So of course you can read. So I can do some really nice little select statements just to confirm that this is a completely empty database. I can pull back the id, first name, last name. There's nothing in there. Let's do a quick insert. And again, we can do this directly through SQL because Sequent is setting up this sync. Let's add Hannah here into the HubSpot account. We'll do a quick insert here and I'll run that and you'll see actually there's an error. We went to run an insert and the error that we're getting back is that I entered your email wrong. Instead of HubSpot, I put a 2 there. Classic mistake. What's really nice here is because sequence running the sync here, it's immediately returning this error in standard postgres. I'll go ahead and fix that. That it'll complete the insert if I go over here and refresh my CRM. There's Hannah right in the database. So pretty nice. If I go ahead and I actually, let's say I fat finger that instrument and I just run it again. Classic. You already exist. And so what's really nice here from a developer perspective is the business logic of HubSpot. You know, there can't be duplicates. These email addresses must be valid. This is a required field. All of that is applied to your database and to your, you know, basically to your caching layer right away.

So.

So let's add Anthony and I in here as well to just get a little bit more meat on the bones. Okay, we'll insert two more. So we now have two more flowing back into HubSpot. Just take a second for it to load here into HubSpot. So we'll give that a second. But if I do a select here in the database, boom. We now have three contacts in the database and I can refresh here in HubSpot. And we got three in HubSpot, so pretty nice. So it can do inserts, you can do reads. So you have this complete postgres database to read from. But let's also Just show updates so you can kind of see how that looks from a developer perspective. The data here is a little messy. I'm completely lowercase. Akamazo is being screamed at you in all caps. We can go back here and I'll just run a quick update. What this update is going to do is it's just going to use a really helpful postgres method initcap. It just cleans up the data and makes it consistent. I'll run that. I need to have a little error there. I need to make this last name, last name, first name, do it. Okay, so we updated the three contacts. If we do another select here, beautiful. We're now readable easy contacts. And if I go over here and update HubSpot, it's all updated HubSpot. So the reason this last name, first name, do it. Okay, so we updated the three contacts. If we do another select here, beautiful. We're now readable easy contacts. And if I go over here and update HubSpot, it's all updated in HubSpot. So the reason this kind of helps teams scale is you're getting the cache layer for free. It's already in your database and you get to interact with that cache layer using pure SQL. So select, insert, update, delete. That's how companies like Fin and Trellis have been able to really pull off these bigger scale initiatives. I'll stop there and we can dig in.

Yeah, thank you for sharing those use cases. I know, I can even tell in the comments a lot of folks have found a lot of value in this. Let's take a minute. Let's actually take a look at some of those questions that we're getting in. First one that's related to this is John mcquared Is one of your other terminal tabs running the polling app that's syncing the data?

Yeah, this is a pure demo. We're really excited to bring out the full.

We literally finished. We just added writes and updates to HubSpot and just last night. So it is running locally on Eric's machine. Not a production yet.

What a great question.

I know. Okay, but let's start. Let's see. So we've got one from Andrea and the question is what if you pass the batch limit request 100 per call, could you suggest some tricks to handle it like having separate batches? Thank you.

Yeah. Andrea, this is a classic problem. So there really is no getting around the fact that you will have to do these in separate requests and you can obviously choose to just do them subscribers subsequently. So fire off one request. If it comes back and fails, fire off the next one or retry it. Or you can do a fan out strategy where you just try to make them all sort of in parallel. But I don't really have any great tips or tricks outside of. It's one of those things you have to do. And it's part of what makes the integration more complicated is more data is moving back and forth.

That's true, I guess. Also this brings up the question, is there ever a time that you would ever not want to use a batch endpoint or batching. Is there ever a use case where it wouldn't be a good idea?

Yeah, I'm tending now to lean towards just use the batch endpoints out of the gate because it means that you don't have to change any of your code when you want to go from 1 to N. And they all, you know, the shape of the requests and the response is a little different. And it's kind of nice to think that you can just write it the first time in a way that'll support just the one you're doing now, but also the more you're doing later. So I really can't think of any situations where the single endpoints are superior. They're maybe a little simpler, but I think it's really marginal. I think the batch endpoints are pretty to use.

Okay, gotcha. All right. And then we do have one more question from Excelsior. How would contact object merging work from a developer perspective? If we're required to do this application side, or would this only be viable via HubSpot?

Yes, you're the main thing you're going to need are those kind of associations between things. So I'm assuming you're referring to maybe a contact object and a custom object and hopefully have an association. Probably do have an association between those two things. What that merging would look like is you would make that request to grab a contact and then in that request you would say give me the associations to this custom object too. HubSpot will give you that back to you if it's. I think you get back 100 associations at a time. So you might, if that contact is very popular and has a lot of other object associated to it, you will have to paginate that. But usually that's not the case. And then you'd go make a second request to go fetch that custom object. So now you have both of those objects in your application code. And then if you want, what I suggest you maybe do is just nest them as A child. So then your application, the sort of detail that they live separately maybe is abstracted away from everything.

Great response. Okay, thank you. And then I guess that's it for our questions. But before we kind of wrap things up, is there anything else that both of you wanted to share? If anybody has questions that pop up after today's webinar, you know, what is the best way to reach out to you? What would you suggest?

Yeah, we're Both in the HubSpot Developer Slack. I think we're both just under our names. We don't have any fun screen names there. Seriously. The door is open. So we're happy to chat. If you have any questions about the HubSpot API or want to ask what we did to handle certain parts of it, we'd love to hear from you.

Thank you both. This has been a lot of fun and I just want to thank everybody who attended today. Today, if you haven't already, please make sure to subscribe to the Developer Blog, our newsletter. I also believe, Dennis, you've been so helpful sharing links with everybody. I'm trying to think. I don't think there's any other anything that we're missing. Thank you. But that's it. We were also talking about maybe doing some blog content after this, just for folks who might just prefer to read or have something to reference afterwards. But this has been great. We're so happy to have you both join us today.

Yep.

Thanks all. And if you're out there and you haven't subscribed to this channel, please do it now. We love you. If you have comments, leave them because we want them. And good or bad, we want to hear it so we can improve. And thank you, Eric and Anthony and Hannah. Seriously amazing stuff.

Yeah.

Thank you.

Thanks, everyone. Great being here.

Fun to be here.

Thank you.

Get out there and build something.

Yes.