Integration Partner

There was a stretch when every software company tried to keep the customer's entire day inside its own product. Write the documents here, hold the meetings here, get the notifications here, and the customer never leaves. The trouble is that a customer's day was spread across several tools from the start. The plan lives in a document tool, the conversation lives in a chat app, the schedule lives in a calendar, and people cross between them dozens of times a day.

So copying things from one place to another became part of the job. A decision made in a document gets pasted into chat. A meeting link gets generated and dropped at the top of a page. Miss one of those hand-copies and half the team keeps working from a decision that changed yesterday.

In sales conversations the problem always arrived as the same question: "we run everything through chat, so will a document edit show up there?" Answering no ended the evaluation. Answering yes required calling into something the chat company had built and published, which is not a feature you can decide to write on your own. It was a question about a relationship with another company, not about engineering capacity.

Integration partner is the name for that relationship. It is not the partner who sells for you. Neither side sells the other's product. Both keep selling their own, and the fact that the two products meet on the customer's screen becomes an advantage each one can point to.

The connection is built out of each side calling the other's API — the published contract that says what one program can ask another for and in what format. The contract has to be open before an outside engineer can touch your product at all.

In practice it takes four steps.

1. Decide what gets joined. Pick one place where the two products overlap: a document edit that posts to chat, a video call that opens from inside a page. What you are looking for is a gap users currently cross by hand.
2. Decide how permission is handed over. A user has to be able to grant one narrow permission — "let this app post to my chat workspace" — without handing over a password to anyone. OAuth is the standard for that, and most integrations run on top of it.
3. Decide how events travel. Instead of the other side polling you for changes, you push a notice to their server the moment something happens. That push is a webhook.
4. Build the place users turn it on. Sometimes a single connect button in settings is enough. Sometimes your app has to be listed in a directory the other company runs.

Once it is joined, maintenance starts. When the other side changes its contract your feature stops working, and a change that stops old usage from working is a breaking change. Customers don't sort out whose fault it is. They contact you first, whichever side actually broke, so it pays to name someone whose job is watching the partner's announcement channel.

Connections tend to land in four places: sign-in, notifications, data, and billing. Sign-in means single sign-on (SSO), where one company account opens several tools. Notifications mean something that happens in one product appearing on the other's screen. Data means keeping two lists or records in the same state on both sides. Billing means your subscription fee being collected through the partner's invoicing system.

Once a product grows past a certain size it stops signing integrations one at a time and opens a space instead. A product designed for other services to run on top of it is a platform, and the directory that gathers up what has been built on it is a marketplace. At that stage an integration partner is no longer a company you negotiate with individually but anyone who follows the published rules.

The money is the other thing that sets this apart from neighboring partnership types. A reseller takes a cut of what they sell. Integrations usually move no money at all, because both sides are doing it to make their own product more useful. The cost shows up as engineering time instead. Budgeting one engineer for about three weeks to build an integration, plus recurring work most quarters after that, is not far off.

"That chat app is an integration partner, so notifications ship this quarter."

The technical connection and the conversation already exist; only scheduling is left.

"They're an integration partner, but we're not in their marketplace yet."

The feature works, but since the app isn't listed on the partner's side, their customers have no way to discover it.

"Their API version is moving up, so I'm coordinating dates with the integration partner contact."

A change on the partner's side could break the feature, and the timing of the response is being worked out.

At Pagedeck the subject usually comes up in a sales meeting first. When Sofia reports that three of five lost deals died for the same reason, Grace decides whether to open a conversation with that company. Once she does, Theo reads through their developer documentation and scopes the build as about three weeks of work.

The work continues after the relationship exists. When the partner announces that an older endpoint closes in six months, Theo copies the date into the team calendar. That the schedule comes from someone else's plan rather than ours says most of what there is to know about this kind of partnership.

The most common mistake is treating the whole thing as a contract problem. Most other partnership types begin with a signature, so the assumption is reasonable. But integrations usually start with engineering, not paperwork. If the partner's interface is public, you can build against it without asking permission; agreements become necessary later, when you want to be listed in their directory or use each other's names in marketing. Invert that order and you spend two months hunting for the right contact while a competitor ships the feature.

The second is assuming that building it is the end of the job. The moment the feature works, it looks finished. In reality every change on the partner's side creates work on yours, and you don't control when that lands. Without someone assigned to maintain it, the way you find out it's broken is a support ticket one morning — and by then the customer has already filed the experience away as your product failing, not the partner's.