Environment credentials

EnvCredentialProvider maps toolkit-specific environment variables into API key, OAuth2, Basic, or no-auth credentials. Every referenced variable must start with:

EYEBALL_CRED_<TOOLKIT_SLUG_UPPERCASE>_

Conceptual custom server wiring:

import { EnvCredentialProvider } from "@eyeball/core";
import { ExecutionEngine, createExecutorApp } from "@eyeball/executor";

const credentials = new EnvCredentialProvider({
  allowedProjectId: "proj_internal",
  allowedUserId: "service_account",
  mappings: {
    stripe: {
      type: "api_key",
      valueEnvs: { secretKey: "EYEBALL_CRED_STRIPE_SECRET_KEY" },
    },
  },
});

const engine = new ExecutionEngine({ credentialProvider: credentials });
const app = createExecutorApp({ engine });

The provider refuses every other project/user pair. This is appropriate for a controlled single-service identity, not multi-tenant end-user OAuth. Rotation, encryption at rest, consent, and refresh orchestration remain your responsibility.

Durable local vault#

For durable self-hosted credentials with a real OAuth authorization flow and automatic refresh, use LocalVaultCredentialProvider (EYEBALL_CREDENTIALS=local-vault) together with your own provider OAuth app and the eyeball-auth CLI. See Bring your own OAuth.

Development fixture vault#

InMemoryDevVault is both a CredentialProvider and the implementation behind the optional /v1/connections routes:

import { InMemoryDevVault, createExecutorApp } from "@eyeball/executor";

const devVault = new InMemoryDevVault({
  credentials: {
    gmail: {
      type: "oauth2",
      accessToken: "fixture:valid",
      scopes: ["https://www.googleapis.com/auth/gmail.modify"],
    },
  },
});
const app = createExecutorApp({ devVault });

It accepts only preconfigured fixture templates, loses all connections on restart, and cannot refresh, encrypt, or run OAuth. The executor enforces that the engine and dev connection routes share the same vault instance.