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
