How connections are authorized
Three patterns, and they differ in who does the work. This is the question every partner asks on a call, and the answer is per connector.
The three-party model
OAuth has three parties: the provider that owns the data, the registered app, and the end user who grants access. The registered app is what the consent screen names — so whoever owns that registration is whose name your customer sees.
Ngentix is a proxy. It moves records on behalf of your app; it is not the app — the distinction is drawn in full on architecture and data handling. Credentials and tokens are stored, encrypted. Record payloads are not.
Which pattern applies is a property of the connector, not a choice: the connector catalog lists what each system supports. Partners embedding this flow in their own product will find the commercial shape of it on the partner page.
The three patterns
The middle column is the one that matters to you: it is how much of the setup lands on your customer rather than on you, and it is the difference between one button and a scheduled conversation with their IT team.
| Who sets up | What the customer does | Whose name they see | |
|---|---|---|---|
| OAuth | You, once per system | Clicks Connect, approves | Yours |
| API key | Nobody | Generates a key in their own account and pastes it — every customer | No consent screen exists |
| Integration record | Nobody | Their administrator completes a multi-step setup — every customer | No consent screen exists |
OAuth — you register an app, once per system
- Create an app on the provider’s developer portal — Intuit, HubSpot, Salesforce. Which systems are covered, and how each one authorizes, is in the connector catalog.
- Paste the Ngentix callback URL into the app’s redirect URIs.
- Request the scopes the flows you have defined actually need, and no more. The provider’s own API reference is the list — Ngentix does not publish a required-scope set per connector.
- That is once per system, not once per customer. Every customer of yours then connects through the same registration, and sees your name.
API key — nothing for you, something for every customer
These providers have no consent screen at all. Your customer generates a key inside their own account and pastes it into your connect screen. There is nothing for you to register, and no way to put your name on the exchange, because there is no exchange to name.
The cost is that it repeats for every customer, and it fails in a way OAuth does not: a key that is rotated or revoked stops working with no notification to anyone.
Integration record — the ERP case
The heaviest of the three, and the one worth setting expectations about. NetSuite is the archetype: the customer’s administrator creates an integration record, issues tokens, assigns a role with the right permissions, and does it in an order that matters.
This is several steps and usually a scheduled conversation with someone who has admin rights. It is not a button. Telling a customer it will take five minutes is how a rollout starts badly.
When a connection breaks
This is the section that gets read at 2am.
| What happened | What you see | What the customer redoes |
|---|---|---|
| Token expired | Refreshed automatically; nothing to do | Nothing |
| Refresh token revoked | The connection reports needing re-auth | Clicks Connect again |
| API key rotated or revoked | Calls start failing | Generates and pastes a new key |
| Permissions changed | Specific operations begin failing | An administrator restores the scope |
| The admin who set it up left | Depends on the pattern | Varies |