Integrations

The failure mode PING designs against: every agent gets its own API key, every deployment gets its own OAuth app, secrets multiply across machines, and nobody can say which credential does what anymore. Each new secret is a new way to fail and a new thing to rotate in a crisis.

The PING pattern instead:

• Humans authenticate as themselves, once, through the platform's native auth. No parallel identity zoo.
• Agents get capabilities, not credentials. Repository access plus the platform's native deployment integration, rather than a personal API token per agent.
• One OAuth application per platform, not one per deployment. Deployments are configuration, not new trust roots.
• Secrets live in exactly one place, resolved at runtime, never copied into worktrees, chat logs, or generated code.

When a platform already integrates two systems (for example, a git host that deploys to a hosting provider on push), PING uses that seam rather than building a custom deployment service or distributing credentials to agents. The agent's loop is: change code, commit, push, verify the platform's preview, merge. No custom machinery, no credential distribution, and the platform's own audit trail covers the deployment.

This website follows the same rules. It creates no OAuth applications, stores no API keys, and duplicates no backend authorities. Where it will eventually talk to PING services, it does so through a defined adapter interface (see the API seam), and the services own their authorities. The website consumes; it does not own.

The integration principles are established and followed across PING's current operations. The website's adapter seam is defined but unconnected by design: there is no PING API to connect to yet, and inventing one inside the website would violate the no-duplicate-authorities rule. Connection happens when the API exists.