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 onboarded through several methods:
| Method | Description |
|---|---|
| Self-registration | Developers sign up directly on the Developer Portal using email and password. Requires the built-in authentication option to have self-registration enabled. |
| Invitation | An administrator invites a developer by providing a username and one-time password. The developer uses these credentials to log in for the first time. |
| SSO | Developers authenticate through an external identity provider (OIDC, SAML, LDAP, or CAS) configured on the portal. See Configure SSO. |
| SCIM provisioning | User accounts are automatically synchronized from an identity provider (such as Okta) using the SCIM 2.0 protocol. |
Account States
A developer account has two possible states:
| State | Description |
|---|---|
| Pending | The developer has registered but the account has not been approved. Pending developers cannot access protected API products or create subscriptions. |
| Active | The developer account is approved and fully functional. |
When self-registration requires approval (registration_auto_approval is disabled), new registrations enter the Pending state. An administrator must approve the registration in the Provider Portal before the developer can use the portal.
If registration auto-approval is enabled, new accounts are immediately set to Active.
Organizations
In the default Developer Portal implementation (based on the 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. |
| Admin | Same as owner. |
| Member | Read-only access to organization resources. |
The organization model comes from the authentication system (Better Auth) used by the Developer Portal Boilerplate. 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 published 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