Why Quiq Flow's Connectors Ask for Your Own API Key, Not a "Connect" Button

If you've connected an app to an automation platform before, you probably expect a "Connect to HubSpot" button that bounces you through an OAuth consent screen. Most of Quiq Flow's 89+ connectors don't work that way — they ask you to paste in a personal API key or access token instead. That's a deliberate choice, not a shortcut we took because OAuth is harder to build, and it's worth explaining honestly rather than leaving it as a UI quirk.

TL;DR

• Most Quiq Flow connectors (HubSpot, Notion, Airtable, Shopify, Slack, Jira, and 20+ more) authenticate with a personal API key or access token you generate yourself in your own account with that service — not an OAuth app QuiQSol registers on your behalf.
• This is the exact same credential you'd generate to connect that service to any other tool — nothing new to create, nothing routed through a shared app that could be rate-limited or suspended by someone else's usage.
• A handful of connectors — Salesforce, Google Sheets/Drive/Calendar, Microsoft Teams/OneDrive/Calendar — do use real OAuth, because those specific providers' own APIs are built around it for this kind of access.
• Your credential is encrypted at rest, scoped to your account, and used only to call that provider's API when a flow you built actually runs.

Doesn't every integration platform use OAuth?

For the big consumer-facing platforms — Google, Microsoft, Meta — yes, and Quiq Flow does too, for the connectors that reach those. But most of what people mean by "the long tail of integrations" — HubSpot, Notion, Airtable, Asana, Linear, Jira, Shopify, WordPress, Discord, and more — actually authenticate through something simpler: a personal API key or access token the customer generates themselves, in their own account, from a settings page that service already provides. That's not us cutting a corner — it's genuinely how those providers' own APIs are designed to be used by a single account connecting its own tools.

Why does that matter more than it sounds like?

Because OAuth apps aren't free to build and aren't free to maintain, and the cost isn't paid by us — it's paid by whoever's waiting on the review. A real OAuth integration usually means the platform (in this case, QuiQSol) registers a developer app with that service, and depending on the provider, that app may need to go through a review or verification process before it can be used at real scale — sometimes weeks, sometimes tied to a specific use case getting re-approved every time a new permission is needed. None of that makes the integration more secure for you. It just adds a queue between "we want to build this" and "you can use it."

A personal API key sidesteps that queue entirely, because there's no app to review — you're not authorizing us, you're generating a credential scoped to your account and handing it to a tool you already trust with other things. The connector goes live the day it's built, not the day a third party's review team gets to it.

Is a pasted API key less secure than clicking "Connect"?

Not in any way that matters here. Both approaches end with the same thing sitting on our servers: a secret that lets Quiq Flow act on your behalf against that provider's API. An OAuth token is that secret with extra steps in how it was issued — it doesn't change how it needs to be protected once it exists. Every credential in Quiq Flow, OAuth-issued or pasted directly, is encrypted at rest, scoped to your tenant, and used only when a flow you built actually runs — never shared across customers, never logged, and automatically redacted from a flow's run history even if the provider's own API happens to echo it back in a response.

The one real tradeoff worth naming honestly: you're responsible for that key the same way you're responsible for any password — if you regenerate or revoke it in that provider's own settings, the connector stops working until you paste in the new one. That's a small amount of your own housekeeping in exchange for zero waiting on anyone else's approval process.

Which connectors still use real OAuth, and why?

Salesforce, and every Google or Microsoft connector (Sheets, Drive, Calendar, Teams, OneDrive) — because those providers' own APIs are built around OAuth for exactly this kind of multi-tenant access, and there's no simpler personal-token equivalent that does the same job safely. We use whichever mechanism the provider actually intends for this, not whichever one is easier for us to build.

What does this mean if you're evaluating Quiq Flow?

It means a connector to a new app is usually live for you the same day you paste in a key — not gated behind a review queue on our end, and not routed through a shared app whose usage limits are set by every other QuiQSol customer using the same connector at once. Your credentials are yours, your usage is yours, and the day a provider ships an API, the only thing standing between you and connecting it is us writing the connector — not anyone approving it.