Port currently issues a single client_id and client_secret pair per organization. All API integrations (Terraform provider, custom scripts, CI/CD pipelines, integrations, webhooks, etc.) either:

Share the same organizational credentials, or

Create separate service accounts, which bypass the client credential model

This creates several critical issues:

Lack of Application Isolation

No way to identify which application made an API request

If one integration leaks credentials, all integrations are compromised

Revoking one application's access requires revoking all applications

No per-app API usage tracking or rate limiting

Credential Rotation Friction

Rotating the organization's secret requires coordinating updates across all dependent systems simultaneously

No way to perform zero-downtime rotation for multiple integrations

Organizations with dozens of integrations face operational complexity and risk during rotation

Emergency credential revocation affects all systems

Auditability Gaps

Audit logs show "organization" made API requests, not which application

Impossible to track which app made which change

Difficult to comply with least-privilege access requirements

No per-app permission scoping

Scaling Limitations

As organizations grow, managing a single credential pair becomes untenable

No way to grant different permissions to different applications

No capability for fine-grained application-level API quotas or rate limiting

Why This Matters

Modern API platforms (GitHub, AWS, Datadog, Stripe, etc.) all use per-application credentials as a fundamental pattern because it enables:

Blast radius containment: A leaked credential affects only one application

Auditability: Clear attribution of API calls to specific applications

Flexible rotation: Each app rotates on its own schedule

Progressive migration: Deploy new credential version while old version still works

Least privilege: Different apps get different permissions

Operational safety: No coordinated rotation across dozens of systems