Developer security
Developer access extends Starfire into external software, so developer credentials must be treated as independent security-sensitive identities.Keep credentials server-side
API keys and service-account credentials belong in backend configuration or a dedicated secrets manager. They should never be embedded into public browser code, mobile application bundles, screenshots, or source repositories.Scope narrowly
Grant only the resource scopes the integration needs. A build automation service should not automatically receive organization billing or unrelated account-management permissions.Use durable ownership
Production integrations should belong to an organization, application, or service account when those capabilities are available rather than to one employee’s personal identity.Rotate and revoke
Replace credentials when ownership changes, exposure is suspected, or policy requires rotation. Revoke old credentials after the dependent application has moved to the replacement.Webhooks
Webhook receivers should verify the documented Starfire event-authentication mechanism when enabled, handle duplicate deliveries safely, and avoid logging sensitive payload data unnecessarily.Logs
Use request IDs, endpoint/status metadata, and resource identifiers for diagnostics. Do not copy API secrets into support tickets or log them for convenience.Test vs production
When separate test and live environments are available, keep their credentials and data boundaries distinct. A test credential should not be assumed to have the same models, billing behavior, or external integrations as production.Organization policy
Developer access can still be limited by the owning organization’s policy, plan, and administrative configuration.API access
Learn the developer credential model.
Applications & service accounts
Design durable non-human integration ownership.