Skip to main content

​
Integration connect links

Some of the integrations you want to connect aren’t yours to connect. The credentials for a client’s CRM, a customer’s data warehouse, or a partner’s API live with someone else — their IT admin, their ops lead, the person who actually holds the OAuth login or the API key. A connect link is how you get that connection done without asking them for the secret or asking them to sign up for Erdo. You generate a link for a specific app and send it to whoever holds the credentials. They open it in a browser, complete the OAuth authorization, paste the API key, or fill in the connection details on a branded screen, and the finished, active connection appears in your organization — the credential is stored against your org, never shared back to you in the clear. They never see your Erdo account, and they never need one of their own.

​
When to use one

Connect links cover both kinds of app Erdo can connect on your behalf:
  • Native integrations — the ones Erdo connects directly, whether that’s OAuth, an API key or basic auth, database connection details (Postgres, Snowflake, ClickHouse), or a service-account key (BigQuery). A CRM, a data warehouse, a SaaS API all qualify.
  • Pipedream-connected apps — the much larger catalog of SaaS apps Erdo reaches through Pipedream (Slack, Notion, and hundreds more). Here the recipient authorizes the app on Pipedream’s own hosted page and the resulting account reconciles into your organization.
Erdo works out which kind an app is from its slug, so you ask for the app the same way regardless. Whichever it is, the point is the same: someone else holds the credentials, and a connect link lets them finish the step without a secret ever passing through your hands. If the credentials are yours, connect the app the normal way from the Connectors tab; reach for a connect link only when someone else has to complete it. The same link also handles re-authorization, but only for native integrations: when a native integration has expired or been revoked upstream, generate a connect link against it so the credential holder can reconnect it in place, rather than rebuilding it from scratch. A Pipedream app has no in-place credential to refresh this way, so re-auth links don’t apply to it — mint a new connect link instead. In the Erdo platform, go to Data → Connectors, find the native connector you want connected, and choose Invite someone to connect from its row menu (on a broken connection, Invite someone to reconnect). Create the invite link, optionally giving the connection a display name so you recognize it later. You get back a URL to send to the credential holder. Treat that URL as a secret: anyone who opens it can complete the connection into your org, so send it over a channel you trust and revoke it if it goes astray.

​
What the recipient sees

The link opens a branded page at /connect that tells the recipient who invited them and which app they’re connecting — no Erdo login, no account creation.
  • OAuth apps send them straight into the provider’s own authorization screen. When they approve, the provider redirects back to a finish screen confirming the connection is live.
  • API-key or basic-auth apps show a short form for the key or credentials. Erdo stores them encrypted against your org and, where the connector supports a health check, verifies them on the spot — so a wrong key is caught immediately and they can retry.
  • Databases (Postgres, Snowflake, ClickHouse) show a form for the connection parameters — host, port, database, username, password, and any options the connector declares. Erdo verifies these with a live connection test before completing, so a wrong host or password is caught on the spot rather than failing later.
  • Service-account apps (BigQuery) show a form for the service-account key, which Erdo likewise verifies with a live connection test before the connection completes.
The form the recipient sees is built from the connector’s own credential schema, so each app asks for exactly the fields it needs and nothing more. When a connector supports more than one method — for example signing in with the provider or pasting a key — the page offers both, and the recipient picks whichever they have access to. Either way, the connection activates in your organization the moment they finish. For a Pipedream-connected app the flow is slightly different, because the authorization happens on Pipedream’s hosted page rather than on Erdo’s own form. The recipient still lands on the same branded /connect screen, but from there they’re sent to Pipedream’s authorization page for the app, approve access, and are bounced back to Erdo’s finish screen. Erdo then reconciles the freshly connected account into your organization. Because that reconciliation can lag a beat behind the recipient finishing on Pipedream’s side, the finish screen offers a Check again action: if the connection hasn’t registered yet, the recipient taps it and the page confirms as soon as the account lands — no need to restart the flow.

​
Expiry, revocation, and single use

A connect link is deliberately short-lived and single-purpose:
  • It expires 14 days after you create it. An expired link stops resolving — the recipient sees an unavailable page rather than a connection form.
  • It completes once. After the recipient finishes the connection, the link is spent and can’t be reused to create another.
  • You can revoke it any time before it’s completed. Revoking invalidates the URL immediately, so a link sent to the wrong person is easy to shut off.
Failed connection modes never leak information: a revoked, expired, or unknown link all resolve to the same generic unavailable screen, so the URL never confirms whether a link ever existed.

​
API, MCP, and CLI

If you’re provisioning connections from a portal or automating onboarding, the same capability is on the /v1 REST API, the MCP tools, and the CLI. Everywhere, you name the app by its slug, not an internal id — a native integration slug (for example github or hubspot) or a Pipedream app slug (for example slack or notion) work the same way; Erdo routes to whichever kind the slug names.

​
REST

Base URL https://api.erdo.ai. Authenticate with Authorization: Bearer <token>.
POST /v1/integration-connect-links returns { link_id, link_url, expires_at, app } — send link_url to the credential holder. Pass integration_id in the body to re-authorize an existing, non-active integration instead of creating a new one; that path is for native integrations only, and the API rejects it for a Pipedream app.

​
CLI

​
MCP tools

Connect links work for both native integrations and Pipedream-connected apps; re-authorization is native-only, so the create tool rejects integration_id for a Pipedream app. Identity and RBAC ride the request context, so a caller only ever mints links for their own organization.