Skip to main content
Connectors are the databases, APIs, SaaS tools, and storage services that your apps, agents, skills, and workflows use. You configure a connector once, and Major holds its credentials and proxies every call, so secrets never appear in your code or your prompts. For the full list of supported connectors, see the connector reference.
  • Secure Flow: Your app connects to the Major API, which proxies requests to your actual connectors.
  • Authentication: Powered by a MAJOR_JWT_TOKEN issued to your session. This token contains your user scopes, ensuring the client can only access what you’re permitted to access.
  • Generated Clients: Major generates resource clients for you. You’ll find one per resource in src/clients/.

Generated clients

When you attach a connector to an app, Major generates a client for it - one per resource, available at src/clients/. You don’t wire up HTTP requests, authentication, or connection setup yourself; you import the client and call its invoke method.
  • Type-safe - full TypeScript support, so inputs and outputs are checked as you write against each resource.
  • Tailored per resource - each connector type gets a client with an invoke signature specific to it, so a Postgres query and a Slack message each use the shape that fits.
  • No secrets in code - authentication is handled by the platform, not your application.
See Resource client for usage and error handling.

Setting up a connector

  1. Navigate to Connectors
  2. Click Add Connector and select the type
  3. Configure the connection details and credentials
  4. Attach the connector to your app via the web editor or major resource manage
Connectors that call a URL you provide, such as Custom API, GraphQL, and custom MCP servers, must point at a public host. Major won’t connect to loopback, private, or link-local addresses.
Resource credentials are encrypted and never exposed to the client-side application code. When you delete a connector, Major permanently destroys its stored credentials, including every user’s per-user credentials.

Completing an OAuth or app-install connection

When a connector uses OAuth (Google, HubSpot, Slack, and others) or a GitHub App install, Major only saves the grant if you finish the provider’s consent screen in a browser that is signed in to Major as the same user who clicked Connect. If the browser is signed out of Major, signed in as someone else, or your session expired mid-flow, the connection is refused and you’re asked to sign in to Major as the user who started it. Start the connection again from the browser you’re signed in to. The same applies to the /connect links agents and apps send you: the link is safe to forward, because whoever opens it starts and completes their own connection.

Shared vs. per-user connections

When you configure a connector, you choose how it authenticates:
  • Shared - one set of credentials for everyone. The person setting up the connector provides them, and every app user and agent run uses that same account. Best for system-owned resources like a production database.
  • Per-user - each person authorizes their own account (for example, their own Google Calendar) instead of a shared login. Only some connectors - typically OAuth services - support this. The connector reference lists which ones do.
For connectors that support it, Per-user is the default when you add one, and Shared is under Advanced. A per-user connector is named after its service (for example, “Gmail”), not after the person who created it. A new Custom API connector starts as Shared. Only its OAuth2 authorization code grant supports per-user, so choosing that grant switches the new connector to Per-user, and choosing a different grant or auth method switches it back to Shared. With a per-user connector, Major gates on the user’s own authorization: anyone who opens an app or runs an agent without a connected account is redirected to a /connect page to complete OAuth, then returned where they were. Because the connector acts as whoever is using it, each person only touches data they’re entitled to. Users manage the accounts they’ve authorized from Connected Accounts.

The connectors list

The Connectors page groups connectors by type, for example “Gmail 3”. Types you can sign in to yourself come first. Within each type, your personal connectors come first, then managed, shared, and ones you can’t access. Each row shows its connection state on a second line: When you haven’t connected a per-user connector, its row has a Sign in button (Reconnect if your sign-in expired). It starts the OAuth flow and returns you to the list.

Per-user OAuth

Full details on shared vs. per-user authentication modes.

Per-environment configuration

When editing a connector, you can configure each environment independently. This lets you use different credentials or endpoints for staging and production. You can also enable global configuration for a resource, which uses a single configuration from the default environment across all environments instead of per-environment configs. When enabled, non-default environment tabs are locked with an explanatory tooltip.

Learn more about Environments

See how to create and manage environments for your organization.

Resource context

You can upload context files - database schemas, OpenAPI specs, API documentation, and more - to any connector. The AI assistant uses this context when writing queries and API calls against that resource, so it understands your data model without you having to explain it every time. If your app needs a connector that hasn’t been set up yet, the AI will show a setup card in the chat - click it to configure the resource inline without leaving the editor.

Custom connector logos

Custom API and Custom MCP connectors can show their own brand logo instead of the generic icon, everywhere the connector appears in Major. When you create one, Major looks for a logo in the background. Connector admins can change it from the Logo field in the connector’s settings:
  • Upload - choose an image file (PNG, JPEG, WebP, GIF, SVG, or ICO, up to 1 MB).
  • Search by URL - find the logo automatically. For a Custom MCP connector, Major first uses the icons the MCP server advertises. Otherwise it uses the icon from the website of the connector URL’s domain (for example, acme.com for api.internal.acme.com).
  • Remove - go back to the default icon. To replace a logo, remove it first and then upload or search again.
Changes apply right away.

Identity-based authentication

For AWS services (S3 and DynamoDB), you can use IAM Assume Role Identities instead of access keys. Create an identity in Settings > Identities, review the generated trust policy for your IAM role, and select identity-based authentication when configuring the resource. For GCP services (BigQuery), you can authenticate via a service account JSON key in addition to OAuth. Create a GCP identity in Settings > Identities to manage service accounts across resources. Identity-based authentication is more secure and avoids storing long-lived credentials.

What uses a connector

The Used by column on the Connectors page shows the apps, agents, and workflows that use each connector. It shows the first one by name, then a count of the rest (for example, Customer Portal +5). Click it to see the full list, with each item labeled App, Agent, or Workflow and linked. A connector that nothing uses shows Not used.
  • An app counts when its latest commit uses the connector, even if that commit isn’t deployed yet.
  • An agent counts when the connector is attached to it.
  • A workflow counts when one of its live connector-event triggers uses the connector.
You only see the apps, agents, and workflows you have access to.

Rate limiting

Set hourly and daily invocation limits on any connector to protect downstream services from runaway usage. When a limit is reached, requests return 429 Too Many Requests until the window resets. Configure limits when creating or editing a connector.

Call screening

Because connectors run on Major’s servers, every connector call - from a generated client, a connector tool, or the HTTP proxy - is checked before it runs for attempts to attack Major’s own infrastructure: running shell or client meta-commands on the host (for example \! in a Postgres query), reading the host’s files, environment, or credentials, or reaching loopback, cloud-metadata, or private network addresses. Ordinary use of your data is never blocked by this check, however broad or destructive - reads, writes, deletes, and schema changes are governed by your permissions, not by screening. A call that is blocked returns 403 Forbidden with the message “this call looks like an attempt to misuse the resource and was blocked”, and is recorded as a failed invocation in the Audit Log. Screening applies to every organization and can’t be turned off. Don’t see the connector you need? Use Custom API, GraphQL, or custom MCP connectors, or click Request it in the Add Connector dialog to submit a request.