Bring Your Own Backend to the HubSpot Developer Platform

The waves are crashing cold on the shore, your back is waiting, don't ignore up bring it here, the platform's clear no fear, no tears. Bring your own back in plug it in, set it free right away feels free Bring your own back in babe, I hope. Custom dreams in every line A sandbox playground, it's your time, no limits, no change build it fast, surf the games, codes aboard, cash the swell HubSpot's open, can't you tell? Bring your own back in Biop plug it in, set it free Ride the way, feel it free Bring your own back in Rewild, No cookie cutter, no one size right it's your wave, you flow your time break the rules, make it sing innovation's a thing he.

All right, well, if you were rocking out to that song like I was, I want to let you know that that song was actually AI generated. So if you heard stuff about BYOB and platform and sandboxes and all that good stuff, that was courtesy of Dennis Edson using Suno. So I love it. So if you haven't played around with that kind of stuff, that's fun. But we're not here to talk about AI today. We're here to talk about bringing your own backend to the HubSpot developer platform. And before we get started, I just want to some of y' all to answer in the chat some of these questions I have for you. So first of all, have you ever built a project on the new HubSpot developer platform? We released it at Inbound in September. So just drop a yes or a no in the chat and if you haven't yet, then you know that we are going to be so excited when you do. All right, we're seeing some people say yes. So let's see our next question. So what is your favorite new feature of the HubSpot developer platform? For my favorite feature, I would probably have to go with App Objects. I think App objects are really cool. They really give you that ability to bring a really good functionality to your customers and have all of that availability for them and, and make sure that, you know, they set up everything correctly the way that you want it to be so that it works seamlessly with your app. And I see Mr. Andy said app homes. App Homes are also great and we are continuing to always make them better for you all. So you can always leave us feedback on our feedback form. We are always happy to hear any feedback that you have. We also have the settings page D. Scott we are going to be talking about app settings today, so that's so exciting that you brought that up. But let's move on because we have a ton to cover today. But I want to introduce you to the lovely panel that we have today.

Speaking.

Hi, if you don't know who I am, my name is Brooke and I am a developer advocate here at HubSpot and I am thrilled to be joined by Jacob Paris, a DX engineer for from Vercel. And I will also be joined by my colleague, Senior developer advocate Hannah Seligson. And we're here to talk about one of the most talked about pieces of the developer platform, connecting a third party backend. So let's just get this out of the way. A note about forward looking statements. Just some of this stuff is going to be in flux, so just remember that if we say something timelines mean change just depending on what happens. So keep that in mind as we go forward. And just to give you a little agenda so we can level set, we are going to start with discussing why you should bring your own back into the HubSpot platform. Then we're going to dive into the how of connecting it and then we're going to have two live demo examples, one with AWS and one with Vercel. Then we will have Jacob we to speak more about using Vercel with HubSpot. And of course at the end we'll save plenty of time for your questions. So we have Dennis moderating the chat. So if you have any questions make sure to throw it in to the chat and he will make sure that we have all of those. So when we get to that Q and A time we will be answering them. So first we need to level set which is if you're new here, what is the HubSpot developer platform? So the HubSpot developer platform is a set of features you can build to add functionality to HubSpot. And these features are housed in a HubSpot project and they include app cards which are what you see on the screen here, this UIE public app with charts. We have webhooks, app objects like I mentioned, app events, agent tools. So there's a ton of more features. On top of that there's telemetry, there's the app homes and the settings page, like all of that. So make sure you check out our docs page all about the developer platform. We will have all of those links down in the description and we'll also be putting those in the chat throughout this time. So if you ever need to check those out, you can go there. So now let's talk about why bring your own backend. So firstly, let's just address the elephant in the room. Currently, the most recent version of HubSpot projects do not support HubSpot hosted serverless functions. However, this can unlock more power and flexibility, including the ability to one write functions in the language that you're most comfortable with, not just limited to what we use, which is Node, JS and React. Additionally, you can directly access any third party databases, including databases that are specific to your customers. All that good stuff. You can also integrate with pretty much any third party API you need for functionality, including ones that you have created yourself. And that's what we're going to be talking about here, using APIs that we've created for our functions. Finally, you can build more complex functions with longer runtimes.

You can.

So with the backend functions you can use a service that allows you to get really complex with your functionality, whereas with HubSpot serverless functions you had a little bit of limitations with how big your functions could get. So now let's just quickly go over some of the differences so that you understand the pros and cons of each. So for HubSpot hosted functions, they are simple to set up and they do live directly in your HubSpot project, so you don't have to be managing multiple repositories and all of your code lives in one place. Additionally, they are built into your HubSpot account, so we host them for you. You do not have to have a third party service for your hosting, which can save you money if you're just running small functions. Lastly, it's good for basic logic, so if you just want to send an alert function to the front end when somebody does something, that is a good way to use a HubSpot hosted function. Now with third party functions though, you get the flexibility in coding language which we talked about. You also have a hostable scalable database. With HubSpot you have limitations based on our public limitations that are on our developer docs. But with the third party functions you're not beholden to that. You get to use whatever database you have. And a lot of those like aws, are very scalable and that gives you even more flexibility. And additionally you can create functions with complex logic. Again, like I said, if you want to run something that has a longer runtime, more than like 10 seconds or so, it's probably better to do that on a third party function place because then you won't be running into errors with all of those functions trying to run and they're too big. So now let's just get it all the way. We've heard your feedback and we know a lot of you have the same question. Question, what if I'm just using a basic function? Well, I am happy to announce that serverless functions are coming to the developer platform. They are on the roadmap for next year. So if you need those simple functions, you can build and deploy them through HubSpot. However, if you do need more complex functionality or you already have a backend you use, we recommend to continue to use that backend and and then call it through HubSpot fetch so you can bring your own custom or third party API endpoints into your HubSpot projects. All right, now let's talk about the how. How are we going to connect our backend to our HubSpot project? So I've broken it down to you in three steps and then each of our examples will kind of go more into detail about those different steps. So the first step is to determine your backend. So, so you really need to choose which backend system you want because different ones have different free tiers or freemium models and you want to understand what you need for what you're doing. So do your research to understand what could work best for you. And here we just have a list of some of the most common backend services and it also includes their local testing tools and the integration tests that you run. So for example, if you're using AWS Lambda, you have the CLI that you can use for testing and then for the integration testing you can test locally with the API gateway. But there are tons of different services out there, so understand what they offer you and then see what works best for you. We are pretty platform agnostic in that way, so you are welcome to try any backend you would like. Nextly, you need to understand the API setup because this is going to be how you actually interface with it. So what when you're interfacing with your backend, like I mentioned, you will be using HubSpot Fetch to call any external APIs. So with this, for example, with AWS, you need to set up API gateway. However, with other things like Vercel, which again we'll go more into detail later, you actually don't need to use an API gateway like that. It's very easy to set up those API routes that you can go ahead and call in your HubSpot project and the last thing you want to do is you want to test it out. This is, you know, obviously the Most important thing, you want to test out both your backend functionality and your API calls before connecting it to your HubSpot app. Which is why with those third party services it's so easy to be able to test locally using Curl. Or you can use AWS's Lambda's backend to do that on the Internet. All that good stuff, you have that ability to test it out, make sure that those calls running. If you want to use Postman, you can do that and all that good stuff. Now let's talk about how the data flows. You have your HubSpot app and then you have your third party backend. How are the data going to flow between these two? Firstly, you're going to use HubSpot fetch to call your backend via the API. Then that is going to return or manipulate the data and then render a response to the front end. So it's a pretty two step process. You call the backend and then the backend returns whatever you need it to do. So you have a lot of flexibility with what that means and you can grab a lot of different stuff. You can use public APIs from other places, you can grab data from different databases. All that good stuff. But now that we've kind of gone over that, let's dive in to some examples. And the first example is going to be presented by Hannah and she's going to go over the wordle app card that she migrated over to the new developer platform and updated it to use the AWS Lambda functions. Thanks, Brooke.

Hey everyone. The wordle app card is essentially meant to guide you. Let's say you already have an application with HubSpot, you're leveraging our legacy framework. What this app does is it provides you guidance on how to essentially manually migrate that application to our new developer framework. And so what it does essentially includes just an app card, includes leveraging AWS Lambda functions and an API gateway. And essentially this just gives you an avenue to understand what are the intricacies or the gotchas when you are going through that manual migration process. But for today, I'm just going to highlight what that back end would look like specifically instead of getting to the nitty gritty of what that migration process looks like. I have a great blog post that will actually guide you through that as well as a GitHub repo that you can test out yourself. We'll be sure to share that with you. Brooke. Next slide. First and foremost, when it comes to the project framework with this, with the new okay, I think you have to press for Each. Thank you, Rogue. Okay, so with the project framework, you essentially first you have your application. This is going to be your HubSpot app. And within that application you're actually going to leverage a config file, and that's going to be your hsproject JSON file. Then within each application you're going to have these subdirectories, and each of those subdirectories are going to be one of those features that Brooke mentioned before. And for this example, I'm including cards, app cards. And within that folder itself, it's containing all of the necessary config files and just react components, files that you are leveraging to essentially create that app card. And app cards are essentially those UI extensions that we offer where allows you to customize a HubSpot record. But in addition to that, where we're leveraging AWS is you've got this app card and you have these serverless functions. What you would be able to do is essentially when you're migrating, you're going to pull your existing serverless functions and then you're going to add it to that third party provider. In this instance, I created a function with AWS called Get Random Word. Within this folder structure, specifically that index JSON file, what I'm able to do is actually write out the code. Then the package JSON is essentially going to be all the dependencies for that function. And then we have this deploy file which is going to essentially contain that deploy deployment script. And then Brooke, will you click one more time? Thank you. And then when it comes to actually deploying this application onto that third party provider, you can use different approaches when it comes to that deployment. You could use AWS offers a serverless application management framework called sam and you can leverage that with a template YAML file. And then you can also leverage something a little bit more flexible with a serverless YAML file. And that's actually going to allow you to have that initial deployment. And then let's say that you need to make changes to your function later on. You can leverage that process and essentially have your overall deployment. But then when you need to make code changes to your function, it allows you to do that a lot easier. Next slide. This is just a close up of essentially what that directory structure is going to look like. I've got a functions folder for Get Random Word, that's the name of my function. But you could include various different functions within that folder and then within that's going to have its dependencies. Next file. This is essentially a script file. And what it's going to do is it's going to allow you to run this script. It's going to start with just an empty AWS account, and then you're going to essentially deploy and create this serverless application. You're going to have your lambda function, your API gateway, and what that API gateway is going to do, it's going to take that function you created and it's going to publicly explode or explode it, expose it. How it does that is it actually allows you to integrate the function into your API gateway and provides a public URL. And then you'll essentially go through those permissions for your IAM role. When it comes to aws, you can leverage different things. When it comes to your logs and any other deployment packages, that's what all that does. Then this next one, it just gives you a UI example of how you could test within AWS console itself. When it comes to testing, I definitely suggest testing before you make that deployment. To test locally, you can utilize all kinds of different testing tools. Like Brooke mentioned, you can also write your own code to test, and then also after you deploy, definitely test as well. So before and after, it's critical that you're executing the test and you're understanding that your function is returning essentially the data response that you need, but also in the format that you need as well. Next slide. Then, like I mentioned, with the gateway, once that you've able, you've been able to expose this public endpoint that you've created that integrates with your function, you're going to essentially expose that on the front end. And prior to our legacy framework, we used to have this run serverless method, but now we're encouraging folks to use HubSpot Fetch, which essentially is an API that allows you to transfer Data within your HubSpot application. After you are essentially creating these serverless functions, you're testing everything out. You need to upload your project into essentially a HubSpot test account and then make sure that data is returning what you're looking for. Right. Next, when it does come to credentials, there is a myriad of ways that you can go about this. In this example, specifically, I just wanted to demonstrate a script and what you can do is you can actually break up the different types of credentials you have. Maybe there's something that is a little bit more sensitive, maybe there's something that isn't as sensitive. Something sensitive could be considered like your HubSpot credentials, could be your access token. If you're leveraging OAuth as well, and Essentially what I'm doing here is I have these two parameter files, they're JSON files, and they are going to serve as basically your different environments for development. So you'll have like a prod, and then you'll have like a developer. And then these are just. This is just like a great way to encrypt all of your credentials and expo and ensure they don't get exposed. That's that next slide. And then this is when once you've essentially you've got everything working on your third party side, you're able to essentially upload your project files into your developer platform ui. What you're going to do is you're actually going to now add your application, this, specifically this wordle card, which is just like a wordle game, onto a contact record. And so in this example, I'm just essentially looking for the app card that I just uploaded into my test account. I'm going to add it to that contact record. All right, next slide. Then once I'm able to essentially add that card to the contact record or whatever record you desire, then I'm going to test that out and I'm going to just ensure that it's behaving the way I'm hoping it will behave within HubSpot. So that's essentially just kind of a small little intro into like how, how that would work with aws. And then if you want to go into the nitty gritty with the migration process, definitely check out that repo and the blog post. And I think we have one last slide. Yeah, so this is just like a little bit of a highlight when it looks like when you need to essentially add that connector between your third party and your application. So we have essentially these permitted URLs fields. And what you're going to do is you're going to include, for this example we have our lambda URL. And this is essentially exposing that API gateway that I talked about, that endpoint, and it's going to collect that data. That's just a close up of what that looks like. Thank you all.

Awesome. Thank you so much, Hannah, for walking through that. Again, if you want to grab this code for yourself, go ahead and go to that Wordle GitHub repo that Dennis posted in the chat. And we also have that amazing blog post by Hannah that will go over the migration process if you're migrating from version 20.25.1 to 2025.2 or higher. All right, so for my example, we are going to be talking about a LLMs TXT file generator. So this file generator is a HubSpot app that takes a webpage or a sitemap URL and and it parses that data on the page to create an LLMs txt file. And that file is just a file that you can upload to your backend of your website. So it's easier for different, like aeo, like website crawlers that are specifically AI. It strips all of the HTML everything. It basically gives you a markdown file that is easy for the AI to read and parse through. And this uses a HubSpot customizable app settings page like I talked about earlier, the Vercel node JS serverless function and Vercel API endpoint. So when we talk about this, we're going to go through the same project structure that Hannah mentioned, so I will go quickly through this. But you're going to have your HubSpot project folder. You're going to have your JSON file, which is going to explain where all of your stuff is, your source folder, your app folder, and then your app hsmeta JSON file, which will have all of that information, including the permitted URLs, and whether this is a static app or if this is going to be for the marketplace. And then inside of that you're going to have your settings folder. So like we mentioned, any type of feature that you add to a HubSpot project now is going to be separated into different folders that are named based off of the type of functionality it is. So for the settings page, you have a settings folder, and then inside of that you will have your JSON file, you have your TXS file with your actual code, you have your package JSON file and all that good stuff. And that's all you'll need for the settings one, you won't need as many files if you're not building a card. And then you also have the Vercel serverless function folder. And inside of there you're going to have your package JSON file and a env file for all of your environment variables and API folder. And then inside of your API folder is where you're going to write your routes. This would be your serverless function TS file, and then whatever your slash API, that's going to be the name of your API call. Now, how do we connect that to Vercel? First, you're going to build your serverless function. So you create that folder and then you add your function into the API folder. It has to specifically be called API. And then next what you're going to do is you're going to, once you've built all of your code and you've tested it, then you're going to go, well, not test it. You could test it locally if you wanted to, but you can also test it after you've uploaded it to your Vercel account. And one of the easiest ways to do that is by downloading the Vercel cli, authenticating your Vercel account, and then running Vercel Dev to upload and start the local development pipeline. And then you can test it. So you can use your local host API endpoint now to test locally with Curl, or you can use an API testing platform like Postman. Then once you've done that, you're going to go ahead and update your URL inside of your HubSpot project. So you have to go to your Vercel account and then you're going to copy over the Vercel domain and use HubSpot Fetch to call that endpoint, and then you're going to go ahead and upload your project. So inside of here, once you've installed a static app, it will show up in that authentication tab and you'll see every single portal that it has access to, and then that will have the private access token, and you will need this access token. So you, you're going to go ahead and copy that over once you've uploaded it to a test account, and then you're going to go back into Vercel to add your credentials there. So in your Vercel account, you're going to go to your settings and then you're going to add the access token as an environment variable, and you're going to make sure that it's set as both production and development. Because if you don't set it for development when you're testing locally, you'll get an error. And I ran into that error quite a bit, and I asked Cursor, what is going on here? And they didn't understand it. And then I realized that I need to say that you could use this in development. So sometimes your issues are just as plain as that. So learn from me. And then you're going to create an env file. Again, this is for the local testing part. So a really great thing about the Vercel CLI is that if you have your environment variables set set in your Vercel backend, you can run vercel env pull to create a env.local file, and that will actually already be populated with your Access token so that you don't need to create that yourself. You can just use the CLI to grab that information. And then how are you going to connect this? Then you're going to test this out in your HubSpot account. And so specifically with app settings, it's a little bit different than what Hannah showed with an app card. So you're going to actually go to the little Marketplace icon in the top navigation bar, and then you're going to go to the connected Apps page. You're going to choose your app from the list of the different apps you have inside of that account, and then you're going to go to the Settings tab within that. And that is where this lives. And the reason why this one is only on a settings page rather than within a contact record page like the wordle app, is because this is supposed to be more of an admin facing type of app. So we really want to make sure that only certain people have access to creating this LLMs TXT file, because that's a lot of data and sometimes it can be sensitive data. So you just want to make sure that it is going to the right people so that only the right people use it. And so then we're going to talk about the API structure. So here we have the example and this one is just going to be your Vercel URL app, that API again, that's why you have to call your folder API and then you just call your serverless function name. And again, like we mentioned before, you are going to add that to your permitted URL section of your app HS meta JSON file. So that is how you do that. If you want a link to this GitHub repo, we have that available as well. So make sure to check out the description and also we'll put that in the chat for you all. But you guys can go around and play with it and try it out and see how it works for you. But now I am going to turn it over to Jacob from Vercel so that he can talk a little bit more about how to use Vercel with HubSpot.

Amazing. Thanks, Brooke. This is super cool. Thanks for having me on here.

Yeah.

I am Jacob Paris. I'm a DX engineer at Vercel working on community platforms. I'm going to tell you a little bit about what Vercel offers and then I'll show you a quick demo I built using Vercel to host a workflow that runs every time I get a new lead in HubSpot. Vercel is a platform that makes putting websites online incredibly simple. You can think of it like this. You write your code, you push it to GitHub and Vercel automatically makes it live on the Internet. There's no servers to manage, there's no complicated setup. It handles all the technical stuff, like making your site fast, secure, available, worldwide. It's the easiest way to take your project from your computer to the web. And that's where it started. So we called this the front end cloud. And then we added backend support so you can deploy backends to Vercel. And then we built this other tool called V0, where you can build apps using AI and deploy those to Vercell. And in order to make that work, we needed to build even more open source tools to make it easier for developers to run AI workloads in the cloud. So we support over 40 front end frameworks out of the box. We've open sourced the tools required to let anyone make a framework that deploys to Vercel. So you're not limited to just the frameworks like React or Svelte or Next JS that we support automatically. We've got full backend framework support like Express, Fastify, Nitro, Hano, as well as full Stack frameworks that deploy both front end and backend code at the same time. If you want to deploy a whole website to Vercel, that works. If you want to deploy just like maybe you have a HubSpot app and all you need is an API route that you can talk to from your embedded card on your dashboard. Vercel can help you out there as well. Then we have V0. So V0 was the first ever text to app tool. You submit a prompt and it generates a full stack application form just from natural language. And then you can deploy that straight to Vercel and that's full stack. You can do environment variables, you can manage the full integration straight through the Vercel interface there. I'll show you a little bit about that shortly. On the open source side, we have our AI SDK, which is the most popular open source tool for talking to AI models through one common interface. So basically all the individual AI companies, they all have their own way of talking to their models and this unifies it into one common format. So you can build chatbots, you can build AI agents, and when a new model comes out that you want to try, all you have to do is change the model name and you won't have to make any other changes to your code. Similarly, we Have AI Gateway, which is our managed platform, and it consolidates all of those providers into one API as well. So you can get billions straight through Vercel with zero markup. And you don't need to have Multiple accounts with OpenAI, Anthropic, Gemini and so on. You don't need API keys for all of them. This all just works through Vercel. And Workflow is our newest toolkit. So traditionally, serverless functions have had really short timeouts, like 30 seconds to a few minutes in the best cases. But with Workflow, we've built durable serverless functions, so we can run long tasks that last for days or months, even all without failing. They'll just pause and suspend when we need to wait on something. And this is using our Fluid computer function system. So you're not actually being billed for the time that the functions are running, it's only when there's actual compute happening. So if you're building AI apps, for example, a lot of the time is just waiting for the AI agent to return with tokens. And now you're not being billed, waiting for that time, waiting for that stream to come in. It's only when each token arrives that we do any processing. This is saved like 95% of sell costs. I have a few more slides, but I can show you all of them in a quick demo here. Jump over. So this is the v0 homepage, which has some community templates you can browse through. Or you just enter your prompt into this text box and it creates a new code project for you which will look like this. I won't do too much about this here today, but the demo project I built, I built entirely in V0, so that's why I'm showing you this. So this is a lead generation form. So I used to work at a mortgage brokerage and I had to build a lot of forms by hand just like this, which were embedded on websites all over the Internet. Whenever new leads came in, all the mortgage agents would get an email and the first one to click the claim button was assigned the lead. So they were in charge of bringing their own leads to the. Sorry, they were in charge of bringing their own leads, bringing their own business. But there were some common forms for the brokerage where they had to kind of compete and race over them. So that's what I built. Here we have the chat on the left. I said, build a beautiful lead gen form intake for a mortgage company to find out how much they can save by breaking their mortgage. This is the UI it came up with on the first shot. This, this whole preview here, this is a live sandbox running on Vercel. So it's not just ui. This is actual. This, this, this looks just like the deployed code. We can see all the code generated here and and. And browse through the different files. I can make changes here. This all works live. We also have the Git integration tab. Anytime I make a prompt here, it's actually pushing this directly to GitHub, which it's a private repo, but I'll make this open for any of you if you'd like to check out. I've also got this synced locally as well. I can jump back and forth between working in V0 and working in my local code editor. I can make changes whichever way I want. If I want to use Cursor here for some changes, I can use that and then I can jump back into V0, for example, when I want to do UI changes. Then we've got the Publish tab, which is the Vercel hosting integration and I can push changes directly through here. Or I can click Inspect and then I can jump to the live deployment here on the Vercel dashboard and I'll run through a little bit of that here shortly. Actually, I can show now. So Brooke showed a little bit about the Vercel cli. I can show that integration here. So if I want to pull my environment variables, I go Vercel envel and I'll pull that into a env file which it created here, which I won't show you because we're on a stream, but that works. And then I can go Vercel Deploy prod to push a new production deployment. So we try to make this as easy as possible to use with as little as few extra steps as necessary. And if I jump back to the dashboard, I should see that new deployment cooking away. But it's the same code as the previous deployment. So we're not going to sit here and wait on that. Let's get back here. Anyway, I built this UI in one go. In the second shot I said integrate with the HubSpot app and send leads to the CRM as they are created. It did a pretty good job. It's a little out of date. It said I needed to add my HubSpot API key. I had to tell it HubSpot has deprecated API keys and now uses an access token and client secret approach, which I think it doesn't show here there, but it looks up the current documentation in order to figure out how to do that and it added that here I've got the environment variables tab on the left where I can add new environment variables manually. It prompted me to fill this one out. So I added the new access token. I've also got a recent API key which I'm only using for transactional emails because that's a paid add on for HubSpot and I couldn't go through the sales contact form in time to complete this demo. Let's see where we scroll up, up, up and. Yeah, so the next step I told it was to add a webhook for every time a new contact shows up. When this form is submitted, we call this API route and it takes the information that the lead entered and it calls this create contact function. V0 automatically created this lib HubSpot file which was nice, which has a few just the functions I need and then it calls the HubSpot API with the relevant info. We can get contact, we can create contact, we can get owners, which you'll see shortly. When I fill out this form, it will automatically create the contact which I can show here. I guess first I told it to create the webhook that route is right here. And it starts my Process Lead workflow that's configured here. I deployed the app from V0 and then I added the webhook here. And this is running on contact creation. It will call this event. It will call this API route Every time a new contact comes in. You could add any webhooks for any events you want to track and trigger your workflows in this manner. Let's see that. Yeah, let's show the code for the workflow. Anyway, so once this webhook is received, we call Process Lead and this is our new workflows toolkit. So this is probably going to be the coolest thing to pay attention to when using Vercel because it unlocks full long running functionalities. We have this Use workflow directive which tells the compiler to turn this into a durable long lived function so there will be no function timeouts. Every time this workflow completes a step, it caches the results so it can rerun anytime it needs to. Anytime it needs to process a new event without reprocessing earlier steps here. So it goes through and fetches the contact details for the new webhook that was just created. So that'll be the form of submission that the user submitted. We then call an AI model doing GPT4 to create a little two to three sentence summary that we will include in the email. And if you'll notice there's no API key or anything included here because this is all automatically handled through Vercel's AI gateway. So if I want to talk to Anthropic or Grok or any other model, all I have to do is change this little model string here. When a new model comes out, I can change that. I can test it out and there's no additional code changes required. So after we create that summary, I'm going to fetch a list of all the owners. So what I want this to do is send an email to every potential owner with a webhook. It's going to have a big claim button on it. That claim button is going to have a link back to this workflow. We're just going to wait until one of those webhooks fires, we get all the owners together. This is Promise Race. This will just wait until the first one comes in. If we wanted a workflow where everyone had to click the button in the email and accept, we can do Promise all instead. But we're racing here because our sales folks are competitive. And then we just assign owner to contact with the winner. And this is another function from the HubSpot API that V0 created. These little wrapper functions are not necessary, but V0 decided to generate those for me, so I'll just let it keep those. I can undo them if I need. I think that's enough. Let's run through the form here. This is one of my tabs. Not too many of them. Let's call this demo user. Let's go. Demojacofaris.com I have a wildcard email set up for these. And let's enter a fake phone number so I can put in my mortgage balance for my house. Let's say I owe $350,000 on it at 4% interest. I've got 36 months remaining and the property value is $750,000. So we calculate and it makes up a number here because the actual math behind this is complicated, but it says I can get an estimated potential savings of 2,100 per year. So this should automatically load in my HubSpot dashboard. So we've captured the lead. I don't have all the columns set up here properly, but all the information I submitted was included in that Create contact function and so it will be here as well. Notably, we're missing a contact owner there. There's no current owner for this contact because we just submitted it. But as the next part of the workflow should send the emails and we get this horribly poorly formatted email. So I can probably improve the AI prompt that was supposed to generate the summary here. Or if we use the HubSpot transactional emails, I'm sure these would look much nicer as well. So this includes the link and this will send out to all of the potential owners and I can click claim this lead, which it successfully claims. And if we view in HubSpot it should now add add the contact. So yeah, we were able to build that whole we were able to build that whole flow pretty quickly in v0. Sorry, wrong tab again, pretty quickly in v0. It understood enough about the HubSpot integration to get me through it and for anything I wanted to do locally I could also jump into my local code base and work back and forth. I can show you the Vercel dashboard for this project and run through a few things there. Now that we have some stuff running on it for a given project, you get to see a little preview of the deployment here you have your configuration. We have all live information on the deployments here. These can come from v0. These can come automatically every time we push to GitHub and they can come from not sure how I'm doing on time here. I'll try and rush through the rest of this. I can also, if I ever want to roll back, I can click a previous one and I can roll back. So if you ever push something you have issues with, you can always go back in time essentially and instantly recover within seconds for the back to a previous version that you knew was working properly. We also have automatic analytics. V0 includes the configuration for this automatically, but it's just one little script you add to your head tag automatically or if you want to embed this on anything you build custom. And we have a shockingly low amount of visitors, but I think these were all me from. You can check your referrers, V0 oversell and so on. Speed Insights is not enabled right now, but this is your lighthouse scoring. We can see the live logs from any period of time. All these workflow steps is just showing internally the API calls that Vercel is making in order to run that workflow. And then we have observability where you can track the. You can see graphs of your usage over time. I want a demo account here so I could go on my full account. I can go back up to a month of data, but here we just were limited to this short period of time. Pretty low activity here on this demo app, so I don't know how much we'll be able to see if I go through here, you can see specific which files are coming. You can see if the cached that's not too useful for API routes and whatnot. We've also got the firewall. This will automatically do bot protection for any. Dismiss all these little pop ups here automatically do bot protection anytime we detect spam, like spam users submitting forms or coming to the track. It's currently set to log those and then I can see if, if we have anything to be worried about. I could also change this to challenge mode which will kind of increase the sensitivity and then it will force them to go through a little checkpoint to verify that they're actual users. And then we have the observability for the workflows I created. So this was the process lead function and it should show all the different run attempts. I've had a bunch of failing ones yesterday while I was playing with the code. This is actually a new ui, so I haven't seen a lot of this yet. This workflow in total took 60 seconds because that's how long it took me to submit the lead to the time when I clicked the email. But we might have some that have taken longer also. 60 seconds, 5 seconds. Yeah, these can run for days or weeks or months even. This one's still running. We're at 31,000 seconds on this one because this one I never clicked the email and so it's suspending indefinitely and there's zero billion for any of that. Great place to run your long running tasks. Then we've got the AI gateway which I showed a little bit about. All you have to do is change your model name and you can get access to all the different providers. And we've also got demos here using this in other languages or over HTTP as well. But I'm a Typescript guy, so I'm going to show you Typescript and then we have our. These are a bunch of my personal projects and stuff there. But we have a full marketplace of database providers that you can connect to for V0 will connect with all these as well if you want to spin up a little app. And if I had told that form that it needed a database, it would have connected and configured Neon or Supabase or something else for me as well. See if I go here, there is a full, bigger, larger marketplace of other integrations we have as well, some for code review for different parts of the process. BrainTrust does AI evaluation and so on. So there's plenty, plenty of options here to handle your integrations. All right, so I covered some of this in the demo here. We have our security, we have our firewall, and the bot management will automatically protect your forms. Our compute functions I can skim over. So these are serverless functions. We run virtual machines in the cloud, but thanks to our new Fluid Compute model, we only charge for the specific milliseconds that it's actually running compute. Anytime it suspends, anytime it's waiting on a network request or for the user to do something else, there is zero charge for that. That has reduced the cost of using Vercel significantly. So there historically have been people ending up with runaway bills if they have things misconfigured or they get sudden large amounts of changes traffic. This has pretty much completely mitigated that issue by switching to this new pricing model. Then we have some observability tools here as well, which I showed and then preview deployment. So I showed creating the new deployments from the command line, but every time you create a new pull request, it will automatically create a preview deployment which you can then you can then view live as well and you can test out the code in a live production like deployment before merging the PR and pushing to production. That's all for the demo here. I'm a DX engineer on the Community Platforms team. That means I spend most of my time hanging out in community vercel.com so if you have any questions you would like to ask, anything else about how to use Vercel or how to work on the integration, you can come over here and we have a great team of people who can give you a hand and help you through your issues.

That's awesome, Jacob, thank you so much for sharing with us. There were a lot of great things out there. But y', all, if you have any questions for us, we have a little bit of time left, so we would love to answer your questions live. We have Jacob here. So if you have any Vercel questions, Vercel slash HubSpot questions, we want to answer all of them. Make sure you put them in the chat and we will be looking out for that. But Jacob, I would love to know from your perspective as someone who has not built on the HubSpot developer platform before and you're saying that the AI was wrong about the API keys, but I would love to know how that process went of setting up your project and connecting it to your HubSpot account.

Overall, it went pretty smooth. The one point of friction I ran into is when I clicked for the new HubSpot apps is it wanted me to create the project via the CLI. Since I already created a project in v0, what I wanted access to was just projects like Crate. Actually, for this demo I did the Legacy app Flow, which was a little easier to get started with.

All right.

Overall, the documentation led me to all the answers I needed to find that part was really helpful. As soon as I searched how to create my API key, the UI told me that this was deprecated and we had the new flow. So I basically just had to copy that back into to BE zero and it was able to look up and adjust the code to the new expectations where I was pretty easily able to set that up. It was a really smooth experience for me.

That's really good to hear. That's great feedback as well. We do have a question about how does one get the Vercel workflow beta access?

Workflow is no longer in beta, or maybe it's still in beta, but it's publicly available anyway. You don't need special access to use it. There is a website I can put in the chat here anyway, useworkflow.dev which is our landing page for it, which helps set it up. I'll paste that in our private chat, but I think someone can post in the main one that gives you the full documentation it runs through. How to set it up if you're using NEXT JS we have I think NEXT or Next or a few other things. We have the immediate setup guides right here, but lots are being created on and this is actually fully agnostic that you could take outside of Vercel as well. On day like two or three, after announcing we had people porting this to other platforms running on their own aws, so there's no vendor lock in here going with this flow. We try to be the best at using it. The nicest developer experience for when you use it, but you should never feel trapped by going with this tool.

Well, that is so cool. I'm definitely going to be trying that out later because I love just the ability to have such a long runtime, but then also just the waiting, especially with I've had my AI where it'll just go in circles and loops and it's like I'm going to get charged for all of this looping and stuff where it's like messing up. So I like that call out to the Fluid Compute stuff. That's really cool when it comes to pricing. All right, we have a question from D. Scott. I typically create an EC2Amazon Linux machine and build my REST backend in Node Express with MySQL running inside Docker container to host my backend. Any compelling reason to switch to either AWS Lambda or Vercel? That's a good question. D. Scott, huh?

Yeah.

Yeah. So the core argument there is whether to use like a long running server or a serverless model. Traditionally, the answer has always been about the access pattern. With a long running server you pay basically a flat cost to keep that server live, whereas with serverless functions, they shut down. Traditionally after each request you only pay for the requests you're actually getting. If you have an app that most of the time isn't getting very much traffic, but occasionally gets a lot of traffic, then serverless is usually a better model, economically speaking, and so on. With our new Fluid Compute is we're trying to treat serverless functions like long running servers. So in the backend we create one lambda and we route like say 30 requests to the same one. It's in function concurrency. So there's not so many of the old serverless problems of like cold starts or issues with new traffic coming up that now needs to be routed to new functions. You kind of get these temporary servers that run and they can handle a bunch of requests at a time and then we will distribute. The innovation with the Fluid model anyway was that as those functions, as those workloads pause to wait on anything, is that we can now route other functions, other amounts of compute into the same lambda instances. It's like incredibly dense, compact compute, which is about as economical as it gets from that point of view.

Awesome.

If you already have your own long running server that you're always running, you are fine to use it. We get a lot of other developer experience benefits from using the Vercel platform. And, and yeah, if you have any other integrations, if you want to talk to any other databases, we make it really easy to set those up as well.

Awesome. Thank you so much for answering that question, Jacob. The next question we have is about HubSpot, but can we use our own backend with any HubSpot subscriptions? The answer is yes, when you have a developer account. Developer accounts on HubSpot are free to use and then you can set up your HubSpot projects through that and then call HubSpot Fetch so it works with any tier. You don't have to have a specific HubSpot account tier. All right, next question is from Vincent. I'm a bit confused on how the separation of backend would work for public distribution. From the demo, you had to manually configure the access key and Secret, which would only work for that specific account. How can that work when I want to distribute the app to another different account? That's a great question, Vincent, and that is definitely something that I am more interested in diving into. That would be the Marketplace version of this. What you'd have to do is you would have to connect to a database to secure all of those OAuth tokens so that you could have it automatically refresh and and do all of that management of those keys. And then you would have to update your backend so that it would call the OAuth tokens instead of just like the personal access token like I used in my example. But you would have to go with like Supabase or Neon, a database which you could easily connect with your Vercel function in order to house those. So that would be the thing that you'd want to do is use the OAuth and then update your code accordingly. There's another question about is there any documentation to implement with Azure functions? Currently there is not, but if you have any requests for different types of backends, we're happy to pass that along to the team and see if we can get some content out there.

It's 12 o'.

Clock.

It's 12 o'. Clock. Which means we are right on time. I love that so much. Thank you all so much for coming and I really appreciate it all, but.

Oh, did we lose Brooke?

I think we lost Brooke.

Oh, wait. Oh my gosh. Did I. Did I cut out for a second?

You did, but you're back.

Oh my gosh. What? That's crazy because I used Google Fiber. Okay, Fiber, whatever. Anyway, what was I saying? Join the developer Slack if you have any questions about your HubSpot apps. Oh gosh, I'm going in and out again. Hannah, can you give the little shout?

Yeah, I'll wrap it up. If you have any further questions, if there's any content examples use cases you are looking for, let us know. You can access us on the develop Slack if you're connected with us on LinkedIn, give us a shout or HubSpot's developer forum. And then if you have any Vercel questions, join the Vercel community. They're wonderful. So please don't hesitate to reach out, ask your questions. We're here to help.

And then if you want to view the slide deck, we have a short link there and you can also scan the QR code and we also have a link to all this and I will also update this with Jacobs links once I get his. So then when you go to that link, it'll just automatically be refreshed with all that stuff. But thank you all so much for joining us. We really appreciate it. And have a great rest of your day. Bye. All the.