Developers
A developer is a user of the Developer Portal who discovers, subscribes to, and consumes APIs. Developers are distinct from API7 Gateway users (who manage the gateway infrastructure) and from consumers (who are provider-managed identities used for access control).
Registration Methods
Developers can be added through several methods:
| Method | Description |
|---|---|
| Self-registration | Developers sign up with email and password when auth.emailAndPassword.enabled is true in the Developer Portal config.yaml. |
| Invitation | In the default portal implementation, organization owners and admins invite people by email to join an organization. A provider-side developer invitation flow may also exist in the Provider Portal UI, depending on your product version and deployment. |
| OAuth login | Developers authenticate through an OAuth provider configured in the Developer Portal config.yaml. Provider Portal login-option settings are unavailable in this released line. |
| Custom provisioning | A source-customized portal can add provisioning such as SCIM. The released frontend does not register a SCIM plugin by default. |
Account States
A developer account has two possible states:
| State | Description |
|---|---|
| Pending | An existing or source-customized workflow has an approval request that has not been accepted. |
| Active | The developer account is approved and fully functional. |
Email-and-password registration creates a portal user. Creating an organization then creates an active developer in the control plane. The released Provider Portal does not expose a registration auto-approval control, and the public APIs do not create developer-registration approval requests. Existing records from another release or a source-customized control plane can still use the Pending state and approval endpoints.
Organizations
In the default Developer Portal implementation (based on API7 Developer Portal Boilerplate), developers belong to organizations. Each organization maps one-to-one with a developer identity in the Provider Portal.
Organizations support three roles:
| Role | Permissions |
|---|---|
| Owner | Full access, including managing organization members and settings and deleting the organization. |
| Admin | Can manage members and settings, but cannot delete the organization. |
| Member | Read-only access to organization resources. |
The organization model comes from the authentication system (Better Auth) used by the default Developer Portal implementation. If you build a custom Developer Portal without Better Auth, the organization concept may not apply.
Developers vs. Consumers
Both developers and consumers represent entities that access APIs, but they serve different purposes:
| Aspect | Developers | Consumers |
|---|---|---|
| Managed by | Developers manage their own credentials through the Developer Portal. | Providers manage consumer credentials through the Dashboard or Admin API. |
| Access control | Developers request access by subscribing to API products. Providers approve subscriptions. | Providers directly assign consumers to allowlists or blocklists. |
| Use case | Self-service API access for internal, partner, or public developers. | Provider-controlled access for internal services or system-to-system integrations. |
Developers and consumers can coexist in the same deployment. However, for a given service, use either API product authentication (developer credentials) or gateway plugin authentication (consumer credentials), not both. Mixing authentication methods on the same service can cause conflicts that require multiple credentials per request.
Cascade Deletion
When a developer account is deleted, the following resources are also removed:
- All applications owned by the developer
- All credentials associated with those applications
- All subscriptions (active and pending)
- All pending approval requests