As a graduate of Y-Combinator, PartnerStack has been rooted in helping some of the world’s fastest growing SaaS companies scale. Companies like Asana, Monday.com, Unbounce, Intercom, and Intuit all use PartnerStack to manage and scale their partner programs, and onboard thousands of partners into our platform.
There are a few unique aspects to PartnerStack, which has led us to becoming the #1 platform on G2.
PartnerStack is the only solution that has both the PRM and a B2B focused marketplace that connects vendors with partners. On average, our marketplace drives a 30%+ lift in revenue for customers.
We are extremely focused on partner experience, which is a big distinction for us. Most PRMs are focused solely on the vendor experience. But if both sides of this equation are not having a good experience, then it becomes a problem.
And with PartnerStack, all of your channels can be managed from a single platform - affiliate, referral, reseller and ambassador. We see a lot of companies, agencies, and resellers choosing our platform to help them consolidate their channels into a single view.
How is your partnership team structured at PartnerStack?
Our team is still relatively young, as we launched it in April. The majority of this year has been building relationships and working with both agencies and resellers.
I lead the team, and we have an incredible Account Manager that works closely with our partners, as well as a partner marketing manager that works on any co-marketing efforts we run with partners.
Our partnership team is currently focused on two core areas:
We often work with sales when one of their SaaS prospects wants to launch PartnerStack right away but doesn’t have the internal bandwidth. In those cases, we connect them with an agency partner who we know can do it right away and do it well.
Technology partnerships are also on our radar. We have recently built a number of integrations. One of our goals in 2021 and going into 2022 will be to further build out our technology partner program and our own integration marketplace.
We also plan to enter the app marketplaces of other SaaS vendors, especially CRMs like SugarCRM or Hubspot. CRMs are good partners for us because, with the exception of Salesforce, no CRM has a PRM as part of their product offering. So our software is complementary rather than competitive. And it benefits our customers to have those systems integrated.
“If you’re planning to scale your partnerships at all, you need the infrastructure in place to do this.”
<center>- Nikita Zhitkevich<center></center></center>
What advice would you give for organizations trying to think through who their ideal partners are?
Ultimately, everything has to come down to revenue. Whether you’re pursuing referral, reseller, or technology partnerships, you have to tie them back to driving revenue.
Especially since you need the support of other departments in your organization, whether it is collaboration with the sales team or the product team to help build integrations, the benefit to the business needs to be very clear.
For agency and reseller partners, I would advise looking to see if they power similar products to yours. I’d also think about whether the partner will continue to evolve over time in the direction you are going and whether they truly understand your product and space.
With APIs taking over the world, more unified API companies are cropping up. But what exactly are unified APIs and do they work well for product integrations?
A unified API is a “meta” data model designed to enable developers to talk to many other systems’ APIs through one interface. The lack of coverage for partner systems’ data fields and methods, opinionated and inaccurate data models, additional dependencies, and increased latency can all be reasons to avoid unified APIs for product integrations.
In addition, a number of unified API companies may be using your customers’ credentials to screen scrape their data from their other accounts, and this can cause lasting damage to your customer and partner relationships.
Ultimately, unified APIs are best suited for product integrations when they are not screen scraping and when they cover a limited number of systems that have a high degree of similarity in their data categories and methods.
The average business uses 110 pieces of software, which is a 9 fold increase from 5 years ago. And they have more and more systems to choose from: there are now 185,000 SaaS apps, projected to be 1m in 2030.
With businesses using so many systems, they need more efficient ways to move their data amongst these different systems. One key way that this data is moved more efficiently is through APIs.
An external API (application program interface) is a contract that is set up between the SaaS application and the rest of the word. It provides a layer of data abstraction that enables systems to more easily talk to one another.
APIs remove some of the work of developers having to understand the idiosyncrasies of each system. It also provides a layer of security, as a partner system does not need to directly access another system’s primary database.
Most modern SaaS companies, once they grow past the early stage, offer a REST API to their customers and app partners. GraphQL and webhooks are also increasingly popular. Older SaaS companies may still use other styles and protocols of APIs, such as SOAP.
SaaS apps’ coalescing around certain API styles and protocols is itself an attempt to reduce the work of integration. Many developers have worked with the REST protocol, for example, and so do not have to learn how to work with it from scratch when they go to build an integration to a new system.
OpenAPI Specification, which is a specification for REST APIs, is also increasingly used, making it even easier to work with and understand other companies’ APIs.
Even if a technically better style or API design comes along, a company has to consider the cost of finding internal and external developers who are willing to learn to work with this style.
Companies usually want to encourage more partner and third party developers to use their external APIs. As a result, the market has naturally moved toward adopting common standards that developers are familiar with.
So if APIs provide a layer of abstraction for systems to communicate with each other, what is a unified API?
Unified APIs (also called normalized or universal APIs) aim to provide an additional layer of abstraction on top of other systems’ APIs and data models.
SaaS APIs already have standard styles and different categories of products tend to use at least a core of similar data categories. Most CRMs will have data resources for Companies and Contacts, for example.
However, every system’s API will have its own idiosyncratic naming conventions, resources, rate limits, and field properties. They also may have different forms of authentication. A developer will have to learn these distinctions if they are building anything but a very simplistic integration.
The idea behind unified APIs is that they can save developers the time of learning the idiosyncrasies of each system. In theory, a developer can connect to a few or even dozens of other systems by just building an integration to the unified API.
Unlike REST or OpenAPI, there is no unified API format or style that SaaS companies are choosing to adopt and follow. Instead, unified APIs are, at this point, proprietary data models imposed on top of other SaaS companies’ APIs or systems.
As the number of SaaS companies proliferate into the hundred thousands, update their product and APIs faster than ever, and SaaS companies do not follow the data model of any unified API company, a unified API company must spend more time constantly updating their data model and relationship to each individual system.
Most systems are designed to enable different business objectives for different types of organizations. Flexibility and customization to the end business’s needs are critical to the software working as designed. Restricting this flexibility or customization can impede the point of the software. As a result, unified APIs must continue to update their model to accurately capture each connected system’s changes and updates.
For example, if a unified API does not contain resources or data fields that are required by a particular system to access core data, then the integration built on that unified API can become useless.
An accounting system may have a resource for Items that were purchased. But it also may have further properties around those items: items grouped into particular Product Categories, or items that are part of a Bundle of items.
If businesses need to track these bundles and product categories to be successful and the unified API does not have any resource or field for “bundle” or “product category,” then the business will find the integration to be of diminishing value.
With current technology, it is not possible to write a unified API that accounts for even most of the important resources and properties in SaaS APIs across the entire market. As a result, unified APIs are focused on one vertical or product category of systems, such as email providers, financial systems, CRMs, or HR systems.
Unified APIs are not proffering a new protocol or style, but rather a unified data model. If the underlying data is widely disparate and only has a 10% overlap in what they are referencing, for example, there is not much to unify.
Accounting system APIs, for example, may have resources around invoices, bank accounts, balance sheet, cash flow, and tax code, while CRM APIs have resources around opportunities, deal stage, cases, lead sources, and forecasting.
Certain resources may overlap across verticals, like company or account resources, but as this overlap is minor, the value of “unifying” those resources for a developer would be small. They would still have to build the majority of the integration by working directly with each system’s API or system and thus have to spend the time to learn it.
But if a unified API is focused on specific verticals and specific use cases, it can unify the data in a way that speeds up development. APIs will often have different naming conventions to refer to the same concept, for example, and this is something a unified API can resolve.
Quickbooks Online’s API refers to the attribute identifying what currency is being used by an Invoice as “CurrencyRef,” while the Freshbooks API refers to this as a property as either a “currency_code” or a “code,” depending on how it is being utilized. A unified API could make a property Currency and then when a developer makes a call to the unified API’s Invoice Object involving the Currency property, the unified API could then send this request to both Quickbooks and Freshbooks, changing the language to reflect each system’s distinct naming conventions.
Even in the same vertical, APIs often differ in ways greater than the naming conventions. Meaning there might not be a 1-to-1 relationship between resources or fields that simply requires re-naming. This can happen in a number of ways:
Unifying around these discrepancies can be challenging and in some cases impossible. One can’t reconcile data that refers to two different things in the world, for example.
One solution to this is to add the distinct fields or resources of every system, but then return a null response from systems that do not have that field or resource. But this divergence obviously undermines the value proposition of only having to work with one API to create many integrations.
Another solution is to allow the developer to directly interact with the other systems’ APIs in addition to interacting with the unified API. However, this also undermines the value proposition as the developer has to then learn both the unified API and the other systems’ APIs to understand what is missing and how to directly call the other API to cover that missing functionality.
Other times, unified API companies may reconcile data in a way they see fit. For example, they may create a Candidate Rank resource with 4 ranking options (adamantly reject, reject, endorse, adamantly endorse) and then decide to put a system that has 3 rankings (never hire, hire, adamantly hire) into the 4 rankings by mapping never hire to adamantly reject, reject to null, endorse to hire, and adamantly endorse to adamantly hire.
As one can see, this is an opinionated model and may or may not capture the underlying intent well or accurately. However, it expands the reach of the unified API.
Even with these limitations, vertical-specific unified APIs can be valuable tools for businesses who need to pull and push data from dozens of systems. These work best when the scope of needed data covered is narrower and the divergence amongst systems’ data models and underlying objects is lower.
Assessing this as a business requires looking carefully at what data and actions might not be covered by using a unified API, and how hard it will be to add that additional data into the business’s workflows, or what the cost would be for not integrating that particular data.
Unified APIs have often been used by businesses to integrate the applications they are using internally. Mark’s Shoes, for example, would use a product like Segment, which, alongside other platform features, has a number of unified APIs focused on customer data, to pull all the customer data from the various accounts they have with website builders, chatbots, CRMs, email marketing automation, etc., and push it into their own databases and warehouses.
This has saved many developers’ time on managing individual system integrations. But a somewhat newer use case for unified APIs is for SaaS companies to use them to offer their customers’ out-of-the-box product integrations.
This embedded use case has the same challenges mentioned above, which is why unified API companies (like when they are aimed at businesses directly) are also vertical specific. But this use case exacerbates many of the challenges detailed.
A business using Segment for their own systems, for example, can spend the time to customize the platform and add whatever code and workflows they need to optimize their own workflows. The business is both using the unified API and is the end user for the resulting integrations.
However, if Luna Email Marketing Automation wants to use a unified API to offer its customers integrations to Salesforce, HubSpot, Netsuite, Pipedrive, and other CRMs, Luna is no longer the end user of the integration. Instead, they are using the unified API to try to provide integrations to multiple systems to multiple different business customers who are all using those systems in their own way.
Luna’s customers are likely operating in a variety of verticals and industries and are different sizes. They have different needs and uses for their CRM. As a result, the desired use cases that are not covered by the unified API can multiply significantly.
Moreover, if Luna wants to provide customers with the configurations for the integration that they need, this means either Luna has to work directly with the APIs of the other systems to offer this additional functionality, or customers essentially have to build their own integrations with Luna’s APIs and the CRM’s APIs.
In addition, the unified API must manage authentication processes for Luna’s customers’ accounts, instead of just for Luna’s account. When a customer goes to install the integration Luna built on the unified API platform, they are giving Luna, the unified API company, and the partner app access to their data in their other account.
It is widely accepted as best data security practice to request access only to the customer data that one needs for an integration use case and no more. However, some unified API companies targeting the embedded use case are likely not abiding by this principle.
SaaS companies build product integrations through using partners’ APIs or through strategic partnerships that grants them special access to data. Some unified API companies, however, appear to be bypassing systems’ APIs (or lack thereof) to grab data to power the SaaS product integrations.
This appears to be because they want to provide access or increased integration functionality to systems that either do not have an external API or have a restrictive partner API.
Unified API companies want to enable SaaS companies to build integrations to all leading software in their vertical. Their value prop is that they significantly streamline the process of building product integrations for SaaS customers. If they can’t “unify” key systems, the value diminishes.
But in some verticals, APIs don’t exist, are only available to strategic partners, or have limited functionality for certain key systems.
The question to ask is how these unified API companies are providing access to data in systems that, you, as a SaaS company, would not be able to access through an API. The answer is - unless they have a legal, documented strategic partnership with the system - it almost certainly can’t without impersonating Luna’s customers’ accounts via a browser and screen scraping them.
So, for example, the unified API company would ask Luna’s customer Mark’s Shoes to authorize an integration between Luna and Salesforce. The unified API company would then use Mark’s Shoes’ Salesforce credentials to directly access all their Salesforce data and then scrape it so it can send the data back and forth to Mark’s Luna account.
If this sounds ill advised, that is because it is.
If you’re a SaaS company considering using a unified API company to provide your customers with integrations, if the unified API company offers: 1) access to system APIs you can’t access directly 2) access to customer account data in systems without external APIs or 3) offers webhooks for resources when the other system has no webhooks for that resource, then you should demand a clear technical answer on how they are doing this.
Ask them how exactly they are getting access to customer account data without APIs or webhooks. If they claim to have special access to a system’s API or database, then ask them to show you proof of that legal relationship.
If they don’t have a legitimate answer for this, there is a real risk they are enabling the customer’s violation of their terms of service on sharing user credentials and taking and storing data from those accounts, which could have implications for the user, the unified API company, and the SaaS company that is enabling this data transfer.
If the other system detects this or finds out about it, they may reset your customers’ account repeatedly, hobbling the integration and the account. They may also choose to ban the unified API company and your SaaS company from ever being an approved tech partner.
Plaid, a unified API company in fintech, recently agreed to a $58 million dollar settlement related to this practice. Part of the complaint against them stated that “at no time were users ever given conspicuous notice or meaningfully prompted to read through Plaid’s privacy policy indicating that Plaid receives and retains access to their financial institution account login credentials.”
While Plaid (valued at $13 billion) can withstand a $58 million dollar settlement from a financial perspective, an earlier stage startup can likely withstand neither a significant financial settlement nor the damage to their brand in the eyes of their partners and customers.
One of the terms of Plaid’s settlement is that they would avoid using the color schemes of banks when asking the end user to authenticate so that the end user would understand more clearly that they were handing their account credentials over to a third party vendor.
Of course for a SaaS company using a unified API vendor to offer product integrations revealing the third party app to their customers undermines the value of white labeling. It is not clear customers wish to turn over their CRM or ATS login credentials to a third party who they have no relationship to.
Plaid also agreed to commit to working with institutions’ APIs so that they did not have to rely on using the user’s credentials and screen scraping data. Indeed, the fintech market in general is moving more aggressively to condemn this practice. When non-disclosed, this type of account screen scraping has already been banned in fintech in Europe.
As a SaaS company presenting this third party vendor to your customers, often in the guise of being part of your product, it is important to ask these questions of a unified API vendor and understand the risks to your partner and customer relationships.
.png)
Not all unified API vendors provide access to other SaaS outside of available APIs and webhooks.
When a unified API vendor is only covering systems who have external APIs or webhooks (or those which it has a legal partnership), there are other issues that should be taken into account before deciding to use a unified API for product integrations:
If you ask all these questions, and get satisfactory answers, unified API companies aimed at product integrations can be valuable in streamlining development. Ultimately, unified APIs are most likely to fulfill their value proposition when they tackle a limited set of use cases that are based on similar APIs in one vertical. It also helps if your customers’ integration needs are not diverse and do not heavily rely on the idiosyncrasies of each system.
.png)
Before selecting a vendor, scope out the integrations your customers need (and will need if you continue to grow) and assess how much coverage the unified API will be providing. If your developers are going to end up having to do significant work directly with the partner APIs anyway, it is likely not worth incurring the additional costs.
If the unified API vendor meets the vast majority of your customers’ integration needs, however, they may be a smart choice for quick development.
