# Transcript
Source: https://speakeasy.com/blog/request-response-anuj-jhunjhunwala

import { NewsletterSignUp } from "@/components/newsletter-signup";
import { anujJhunjhunwalaEpisode } from "@/lib/data/request-response";
import { PodcastCard } from '@/components/podcast';

<div className="max-w-4xl mx-auto my-8">

<PodcastCard {...anujJhunjhunwalaEpisode} />

[Anuj Jhunjhunwala](https://www.linkedin.com/in/anuj-jhunjhunwala/) is the Director of Product and Design at [Merge](https://merge.dev/).

In this episode, Anuj shares how Merge is transforming integration pain into product velocity with their unified API approach. We discuss:

- The pain of building and maintaining custom integrations
- How AI is making integrations table stakes for modern products
- The three types of data that matter for AI applications
- Why proprietary data accessed through integrations creates competitive differentiation
- How AI is changing API design expectations and consumption patterns
- The evolution from traditional CRUD to richer, contextual queries
- What great developer experience really means in practice

### Listen on

[Apple Podcasts](https://podcasts.apple.com/us/podcast/ais-impact-on-api-integration-patterns-and-building/id1801805306?i=1000713359298) | [Spotify](https://open.spotify.com/episode/247AHOYYfswDokKxruYk7F)

<iframe
  title="Request // Response: AI's Impact on API Integration Patterns and Building Frictionless Developer Experiences"
  width="100%"
  height="180"
  frameBorder="no"
  scrolling="no"
  seamless
  src="https://share.transistor.fm/e/8fdd5cbf"
></iframe>

<NewsletterSignUp />

</div>

## Show Notes

[02:30] – The pain of building and maintaining custom integrations
[03:45] – Merge as "Plaid for B2B software" and the magic moment for devs
[07:30] – AI making integrations table stakes; the three types of data
[08:30] – Why proprietary data is the key to differentiation in AI
[09:45] – AI and the future of APIs: personalization and intuitive design
[11:30] – DX vs AX: API design for devs and for AI
[12:00] – How AI product patterns are changing API requirements
[13:00] – Richer queries, delta endpoints, and evolving API design
[14:00] – The rising importance of fine-grained permissions
[15:00] – HubSpot, search endpoints, and future-facing API choices
[16:00] – Delta endpoints explained and why they're valuable for LLMs
[17:00] – Principles of great developer experience: predictability and frictionlessness
[19:00] – Where to learn more about Merge

## Key Quotes From The Discussion

### API Integrations are Table Stakes for AI

> "The biggest trend is that it's just becoming table stakes, API integrations. We talk to a lot of AI companies. We get a lot of interest in AI companies, and there's really like three types of data that is helpful when you're building an LLM, right? There's the public data that exists out there that's scraped from the internet and is publicly accessible. There's synthetic data, which is obviously produced itself by an algorithm or by an LLM and can help you validate and test out edge cases. And then there's proprietary data, right? So it's the data that belongs to your customer."

### The Magic of Proprietary Data

> "The proprietary data is data that's specific to you and makes you different, and it's a thing that no one else can get access to because it literally just belongs to you or your customer. That I think, is the magic of the integration, is that the integrations pull in that third bucket and like they can make your product different, so you're leaving money on the table if you don't have an integration strategy because you're not thinking about that third bucket, which actually makes you different."

### AI's Impact on API Design and Documentation

> "APIs in general just have to be extremely intuitive and easy to get started, right? So like AI, I think, spoils us at a very high level into expecting a lot of personalization, right? When you go to ChatGPT and you ask it a question, it can feel like a very pointed personal response to what you just said. It's a unique answer in many cases, like the exact question you have. Separately, but also relatedly, no one reads docs, right? No one reads anything."

### What is Great Developer Experience?

> "I think ultimately what this boils down to is that great DevEx is reducing friction to the point where your team can spend its time on other high-leverage things that you'd rather spend your time on, right? That's ultimately what this is—providing leverage. It's multiplying your team. It's a force multiplier, and I think that's super powerful just because out of the box you click a few buttons on a website and it can do that for you, which is a really powerful experience in my mind."

## Referenced

- [Merge.dev](https://merge.dev/)
- [Plaid](https://plaid.com/)
- [HubSpot](https://www.hubspot.com/)
- [ChatGPT](https://chatgpt.com/)

Production by [Shapeshift](https://shapeshift.so).

For inquiries about guesting on Request // Response, email [samantha.wen@speakeasy.com](mailto:samantha.wen@speakeasy.com).

## Frequently Asked Questions

### What is Merge and what does it do?

Merge is a unified API platform that makes it easy to add hundreds of integrations to your product. Think of it as "Plaid for B2B software" - they span HR, accounting, ticketing, file storage, CRM, and other categories. Instead of building individual integrations to tools like SharePoint, NetSuite, or Jira, you integrate once with Merge's API and get access to all their integrations.

### Why do companies choose Merge over building integrations themselves?

Building custom integrations takes weeks or months per integration, requires ongoing maintenance, and can become a blocker when customers need integrations you haven't built yet. Merge eliminates this by providing pre-built integrations that are maintained by their team, allowing companies to focus on their core product instead of integration infrastructure.

### How is AI changing the importance of API integrations?

AI is making integrations table stakes because of the three types of data useful for LLMs: public data (accessible to everyone), synthetic data (generated by algorithms), and proprietary data (unique to your customers). Proprietary data accessed through integrations is what creates competitive differentiation, making integration strategy critical for AI companies.

### What are delta endpoints and why do they matter?

Delta endpoints return only what has changed in a database over a specific time period, rather than requiring you to iterate through all records to find updates. This is particularly valuable for AI applications that need to efficiently process large amounts of data and understand what's new or changed.

### What makes for great developer experience according to Anuj?

Great developer experience is about reducing friction to the point where teams can spend time on high-leverage activities. It should be predictable, stable, frictionless to get started, and act as a force multiplier that gives developers superpowers by handling complex tasks seamlessly.

### How is AI changing API design expectations?

AI is creating expectations for highly personalized, intuitive experiences similar to ChatGPT. APIs need to be extremely easy to understand and use, as people increasingly rely on AI tools instead of reading documentation. This is driving the need for more intuitive API design and better out-of-the-box experiences.



[00:00:00] Great Dev X is reducing friction to the point where your team can spend its time on other high leverage things that you'd rather spend your time on.

Hey everyone. Welcome to Request Response. I'm your host Ser CEO, and co-founder of Speakeasy. We are the modern tool chain for REST API development. I'm joined today by an Who runs the product and design Teams at Merge. Great to have you here today. Great day's going. Great. Thanks for having me on. I'm excited to chat.

Yeah. I had the, um, opportunity to visit your office, uh, last year. I think it's really interesting Merge holds this, uh, place in the API ecosystem. As you know. I think one of the first companies that really, um, popularized being an API company and not, not a company selling an API necessarily, but actually.

Building a product or tool for other API companies. So really excited to chat. Just before we get into all the, all the fun stuff happening in the a p world today, I love [00:01:00] for you to share about. What, what merge actually does today, what your role is, how you, how you ended up there. Merge in a nutshell is a unified API.

We make it really easy to add hundreds of integrations to your product. So think of it as like plaid for B2B software, we span hr, accounting, ticketing, file storage, CRM. There's a bunch of different categories we offer these integrations for, but let's say you want to pull from your customer's SharePoint or NetSuite or Jira.

We make that very simple. So you don't have to build those integrations yourself. We build the integration for you, or do you have the integrations built? You integrate with our API and you get access to all the integrations behind the scenes. When you see the problem of building integrations, you're like, I need this.

This is one of those things that just saves me time and effort, not only in the initial build, but it also helps with maintenance, right? Because over the long run, these integrations break third party providers, change the endpoint. There's things that happen and we just handle all, all that for you, including the observability.

So. It can save you a lot of time and energy. What I do here is I, I run the product and design team. It's a series B startup. We are growing rapidly. We're about [00:02:00] 115 people, uh, spread across New York, SF and Berlin. There's a lot that goes with that, right? There's the, um, ambiguity of how do you go from series B to series C.

There's a lot of exciting things that we want to build a lot of. Uh, great customer feedback we get and prospect feedback, and it's just balancing all these things and making sure we're building the right things at the right time, which is a, a very, uh, exciting challenge to be working on.

Yeah, that's super cool. Such a unique. Place to be as, as a company, you know, as someone who's integrated a lot of APIs myself, as a developer, why do you think people come to merge? Like as a, as a developer, is there like a singular pain point, a singular kind of magic moment that, uh, would make me. So like, Hey, I would rather use Merge than go do all these integrations myself.

It's probably easiest to like use an example. So let's say you're a PM at a financial forecasting company. Like your, your job, your product is to help your customers with their financial forecasting. And so what you need to do that is you need. Your customers to somehow provide their financial data, their transactions, their journal entries, all this information that lives in [00:03:00] NetSuite or QBO or Sage, right?

It, it's all in these accounting tools. And what you could do as a PM for this company is build an integration to all these different third party providers. You could have your customers upload the data, but no one wants to do that, right? No one's gonna sit there and. You know, fiddle with CSVs and all that.

So, um, neither of these options are particularly enticing because to build your own integrations, each one takes weeks, months of time to do. Docs can be arcane and opaque. It's hard to understand exactly which things mo a map to what some of these integrations have, multiple APIs that just, you know, it's unclear how they kind of play together with each other.

And you have to figure out things like authentication and pagination and rate limits and, you know, again, like these things can change over time as well. So you have to constantly maintain them. Keep an eye on things. You come to us and you integrate straight With Merge, you integrate with our API and behind the scenes you have access to all these different accounting integrations and your customers have this little popup box, kind of similar to Plaid, where if you go to like TurboTax and try to log into your, or pull your bank information in, your customers can come to your portal.

Click on a button [00:04:00] that says, connect my accounting integration, or connect to my accounting software and pick the software that they, they use authenticate, and that's it. And to extend this even further, it's not just accounting, right? So there's, you know, this financial forecasting example, maybe you want compensation data or headcount spend and you need that from the HR platforms.

Or you need pipeline data to understand like how your sales are doing. So you wanna pull that from Salesforce or HubSpot customer tickets. So you wanna analyze turn risks, so you want ticketing data. All of a sudden you're not just building like four or five integrations, you're building 50 integrations.

What's tricky here and what people don't fully see all the time, is the fact that if you sign a customer as the PM at this financial forecasting company that needs some accounting software, you have not already integrated with. That becomes a blocker for you, right? Because all of a sudden you need to get their data, you need to build that integration.

So what Merge does here, and what's really beneficial is not only do we provide this all outta the box for you, we have built all these integrations in-house. So. If you have that additional new customer who, who signs on chances are we support it and it's just a click of [00:05:00] the button to enable it for them.

Yeah, that's really interesting. I think as you were saying, that's something that came to my mind as as a developer, is like when you build integration, it's now this live thing, right? It's this thing that needs maintenance. You need to kind of constantly put. Cycles velocity into it to keep it up to date, keep it healthy, keep it monitored, uptime, all that stuff.

And it just kind of occurred to me that, you know, if I have to do that, you know, end times, as you said, instead I go to you, that's a company that's pouring all that, all those cycles into one API. Right? Your unified API. And I get probably many hundreds of dev years of time spent into that one API. It's just something that I've been thinking about a lot as, as also someone, you know who runs a company and we we're a vendor to other companies.

How do you explain the value of having someone. Hyper-focused on that problem for you. And I think in your case, it, it is really apparent because you are aggregating many APIs and making it one. And so it's so obvious that like those hundreds of APIs, the, the time you take to integrate all [00:06:00] of them, the health and upkeep of all of that now just compounded.

It's like kind of like compounding interest just built into one API. So that's, it's a really fascinating, uh, business model that you guys have. It's one of those things that really accelerates. The growth of our customers. At the end of the day, they have to spend a lot of time doing this in-house. So I guess there, there's like three options, right?

There's one option, rebuild these integrations in-house, and that takes a lot of time and energy and slows down your roadmap to build other things. There's number two, which is that you don't build integrations at all, which either provides a worse customer experience for your customers, or it means that you're missing the boat.

Right, because ultimately you need this data from your customers. That's what differentiates you as a business, is getting your own customer data and using something, doing something with it. Or the third option is you use Merge A Unified API that has all these integrations built outta the box and significantly speeds up your time and saves your money as a business.

You guys also have such an interesting vantage point because of where you are with. The one API to rule them all. That vantage point must give you kind of very interesting perspective [00:07:00] on some of the shifts you're seeing in the API integration. I think, you know, one thing, uh, listeners and, and really everyone I work with is always asking me like, how is AI going to evolve API integrations?

Like, is it going to make it so you don't need a unified API? Is it gonna make it make the problem worse? People still have to do these integrations, put them in production, right? It's easy to do, like. Pull up cursor and then make integration for fun deploy. But then that looks very different than someone running an at scale production system.

So I'm curious to hear your take on, on what's going on on the ground. The biggest trend is that it's just becoming tables stakes, staff integrations. We talk to a lot of AI companies. We get a lot of interest in AI companies, and there's really like three types of data. That is helpful when you're building an LLM, right?

There's the public data that exists out there that's scraped from the internet and is publicly accessible. There's synthetic data, which is, you know, obviously it produced itself by an algorithm or by an LLM and can help you validate and test out edge cases. And then there's proprietary data, right? So it's the data that belongs to your customer.

[00:08:00] And the first two things there, the public and the synthetic data. Are accessible to basically anybody. The proprietary data is a data that's specific to you and makes you different, and it's a thing that no one else can get access to because it literally just belongs to you or your customer. That I think, is the magic of the integration, is that the integrations pull in that third bucket and like they can make your product different, so you're leaving money on the table if you don't have an integration strategy because you're not thinking about that third bucket, which actually makes you different.

Maybe more broadly, the role of AI in changing how APIs are consumed and built. APIs in general just have to be extremely intuitive. And, uh, easy to get started, right? So like AI, I think, spoils us at a very high level into expecting a lot of personalization, right? When you like go to chat BT and you ask it a question, it can feel like a very pointed personal response to what you just said.

It's, it's a unique answer in many cases, like the exact question you have separately, but also relatedly, no one reads docs, right? No one reads anything. Um, they, you know, they just, uh, I'm at the point where if I use a third party tool or if I am. Figuring out how to troubleshoot something at home. The first thing I do is open up chat GBT [00:09:00] and like take a picture of it and say, how do I use this thing?

And so I think people are, they're using AI to personalize the type of responses they get. They expect low friction in all these encounters. And so in the future you're gonna get to a world where no one's gonna read draw docs. What they're gonna do is they're gonna go to Chacha bt and say, how do I do this thing?

And so it's on, it's incumbent. It's easy, it's it. Absolutely imperative that as a business you make it very simple to understand what you do and that extends to the API. The API needs to be easy to understand. It itself is a product, so people need to understand like what the different endpoints do. Why are they using this API, what's the advantage of it?

And it can't be this like very non-standard thing that makes it hard to actually build an integration on top of. So that's kind of like a maybe broader point on just like how people, how I see ai. Changing the API I landscape over time or ways that products can differentiate today in the world of AI is by having access to more data, right?

Like you said, and integrations are the way to get that. So I think that's, that's a really great take because that's a, that's a really strong tailwind for unified APIs and API integrations more generally. It's kind of moves them from bringing, I [00:10:00] guess, something further down the task list to table stakes, right?

Like now you just need to integrate with. As many systems as you can get, as much data. Make sure that any AI experience you have in your product has maximum access to different data behind different services. So that, that really resonates with me. I think the other interesting thing you said is like a lot of APIs are just not intuitive to use.

Humans really struggle with that. Maybe AI can help us there, like actually do that process of like reading docs, understanding how to use this, the gaps. It's so funny because I think just earlier today I was, I made an MCP server for an API, it was an MCP server for our, um, internal API, so our own kind of admin endpoint that we have that has our customer data.

So, you know, one of the things we do is like we generate SDKs for customers and I was looking at. Who was the last person we generated SDKs for web that has web hook in there. It gave me the results back, but it left off like the one customer I wanted. And then I asked, why did you leave it off? It basically said, I got confused with the pagination style of [00:11:00] this API.

And I was like, that's kind of hilarious because it's probably what would've happened to a human too, and like this thing is struggling with the most non-I part of our own API. So yeah, I think just a long way of saying, I think. Something that all of this drives us towards is actually API design is even more and more important.

It probably has like diverging branches. You have great API design for dx Great. API design for ax, the new hot term on Twitter X. That's really kind of an interesting take that you had that really stands out to me is. Um, a lot of this is actually tailwind for some of the things that we already do. As all of this moves forward, how do you see some of these consumption patterns changing as people build more actual real AI product applications and not, not just attempting to use AI to do integrations, but people have products that showcase to their customers energetic experience or chat experience or some other AI experience.

How's that gonna like, pull or push you guys in? [00:12:00] What people want from the API integrations. I think there's three major things that come to mind. So the first one is an increase in breadth of what kind of data AI needs ultimately from these different APIs, right? So like inherently, AI has less friction in processing and using data just inherently in how AI works.

Um, it's gonna need more data from more places, right? You're not limited by a human processing data. You have this machine that's doing it. It can just do more of it faster. So you can need more data from more places. I think also proprietary API data helps ground. LLMs and like avoid hallucination. So the data becomes more important to feedback into the system, just to like test out the products you're building.

And the more structured and reliable that access is from more places, the better it is. So it kind of all ties together in like helping expand the breadth of the data that AI has access to. I think it also. Leads to more, I call almost like contextual queries, right? So I, I think traditional crud is kind of going to give way to richer queries.

Like give me all candidates hired in the past year group by department with average time to hire, [00:13:00] right? So there's like very rich questions you can ask of an LLM. And so things like bulk fetching, delta endpoints are gonna be more important. You wanna have caching strategies to preempt that, right? So there's like different ways you wanna like set up the API itself to kind of return the data in a way that is.

Tuned towards a customer in this case, uh, an AI like an LLM that needs more data faster. You're not kind of like limited by some of the old rest API design patterns, if you will. And that leads to the third one, which I think is that permissions are gonna matter a lot more. Mm-hmm. Um, right. So if you're pulling data from ticketing integration or Google Drive or SharePoint, for example, there's a larger surface area.

To accidentally expose data for the wrong users. Right? And so you wanna be very careful in how that works. And that's something we take very seriously when we build these integrations. So I think those are kinda like the three big things that come to mind is like there's increased, increased breadth of the kind of data that you're looking at.

The queries themselves can get richer, and that leads to changes and kind of evolution in how APIs are designed. Even a change in user consumption patterns, which is where permissions comes in. Um, and you wanna make sure that. [00:14:00] You really lock down the kind of data that any given user has access to at any given time on the build side for APIs, I think we can expect maybe a couple things that are.

Better user experience related. Earlier you were saying like, we're no longer beholden to crud the way that rest APIs traditionally get built. Another kind of just anecdotes from today for me is I was, um, one of the MCPS that I use the most is HubSpot. So I don't have to cut to HubSpot ui, I can just, you know, figure out what our deal pipeline is like, what the deal stages are and, and things like that.

And I found that HubSpot does actually really well with MCP. Because most of the tool calls when you peer under the hood and look at what it's doing, it's not using the, the crowd endpoints. They have a search query endpoint built into the API spec. And so the LM is opting to use that nine times outta 10 instead of like trying to do tool discovery and like actually say, you know, if I wanna find out the, the deal state for.

Company Y and then this is like the deal values of doing those tool individual API [00:15:00] calls. It's actually just doing a search and letting HubSpot, I forgot, you know what, what it is. So, and I think that's kind of exactly what you brought up, right, is there are certain types of APIs that are going to get more.

Probably be more used, more powerful, higher leverage. In this world of, of Chat first, or even agent first, our day to day we run into so many API specs for companies. That's such a core part of what we do. I think being able to help customers understand like design choices, how that might play out later on could be a really interesting thing to do.

But you said this term, Delta endpoints. Uh, what, what is a Delta endpoint? So a Delta endpoint in a nutshell just basically returns. What has changed in the database itself, right? So if you wanted to see all the things that have changed in the past week, the records that have been updated, for example, it, it allows the API to return exactly what has changed.

So you can see the, the, the delta, the changes in that. It just makes for a more efficient response. You don't have to like iterate through and see when the last modified ads, uh, timestamps have been updated. It's just a more efficient way of returning data, which is super helpful because LLMs again, like.[00:16:00]

When they need more data, when they ingest more data to begin with, you wanna make it as simple as possible for them to understand what has changed in that data itself. Um, and so we're seeing kind of the rise of that endpoint, which has been very helpful on our end. And when we're, you know, integrating with these third parties when they have that endpoint, it makes things a lot easier on our end as well.

Okay. That, that makes a lot of sense. I think, I've actually not worked with Delta Endpoints myself, but it's, it's, the pattern sounds very similar to. Change data capture database event streams where you start to look at like, yeah, you get what's changed and you act on that as opposed to doing queries. So yeah, I, I think the, the tech technology behind it makes a lot of sense to me.

Yeah. As we come to the end of this, I wanted to also ask you again, as someone who builds this amazing product that devs gonna use to not do a bunch of other work, what does, like other particular points of view principles you develop over the time, over your time emerge on. What does great developer experience look like?

If you are designing a new product, are there high level principles or philosophies you, you try to follow [00:17:00] to get to great dev? The first one that comes to mind is that we want to make things as predictable as they can be. So like the one thing you don't want to have unpredictability in or chaos is your a i integrations, right?

Because it's ultimately your data, your customer's data that we're pulling in. You want it to be structured and understandable and, you know, ease of understanding is super important here. The one thing we never want to do is ship a breaking change, right? So like we want to keep things stable, easy for you to understand.

If we do need to change something, we're gonna give you ample notice and you know, a heads up on why it's happening, but. We don't wanna do that that often. And I think that that kind of comes to the second point, which is a good developer experience is ultimately very frictionless, right? So you can like, sign up for an account, start testing it out, low cognitive load, right?

You don't have to read a lot of docs or understand a lot of things upfront to start seeing how you can, how this tool can provide value for you. Um, it doesn't require a lot of explanation and um, I think this all kind of come together, right? It goes back to the point earlier about when you use chat, bt it's a very like.

Tailored experience outta the box. You just start asking it questions and it returns [00:18:00] data to you. We're not quite there yet. I think with API integrations, there's a lot of, you still have to build the integration and, and, you know, ingest a unified API, but I think we're, we're headed towards that world where right outta the box, you sign up for an account and it makes sense.

It's just like, this is what this does for me. This is why I need this. This is where, you know, the different models live and why I need to access all this data and do something with it. That makes this a very powerful user experience, I think in my mind. I think great developer experience really does have to give you kind of a, a feeling of having superpowers, right?

You like, you do something, uh, it's so seamless, it's so frictionless that you've got hours back in your day and, and as a result you're like, this thing is, uh, yeah, is, is compounding value for me is like a huge point of leverage for me. So, yeah, that makes a lot of sense. I, we we're a develop experience company, so I, I always love to ask this question, kind of see how people think about it.

I've heard all kinds of. Crazy things from great DevX means that you should work on an airplane offline to great DevX means, um, you don't need to talk about DevX, right? Like, it [00:19:00] just, it just works Such an important point for like products like this that we work on. I think ultimately what this boils down to is like great DevX is reducing friction to the point where your team can spend its time on other.

High leverage things that you'd rather spend your time on, right? That's ultimately what this is, is providing leverage. It's multiplying your team. It's a force multiplier, and I think that's super powerful just because out of the box you click a a few buttons on a website and it can do that for you, which is a really powerful experience in my mind.

Well, that brings us to kind of the end of our time here, uh, and thanks a ton for joining us today and just for everyone here who tuned in, if they wanna learn more about what you do or get in touch. Uh, where should they go? Well, thanks for having me on our website is merge.dev. You can follow me on LinkedIn as well.

We have a lot of great things coming up and we're really excited to, to talk to you more. I'll be excited to have you back in the show here in a couple of months as AI evolves and we really have to see how people, how integration change. Yeah, will do. Thanks. Thanks for having me [00:20:00] on.