Organizations
To add a new organization, press the + Create button in the top right.
When Create is pressed, the organization is saved by filling in the information on the screen that appears.
The fields used for organization configuration are shown in the table below.
| Field | Description |
|---|---|
| Code | Short code that identifies the organization. |
| Name (tr) / Name (en) | Turkish and English names of the organization. |
| Parent Organization | The parent organization that this organization is linked to. |
| Notification E-mails | E-mail addresses used as dynamic recipients for organization quota alerts. |
| Source | Shows where the organization record comes from: Manual (created directly in Apinizer), LDAP OU, LDAP Group, or OIDC Group — together with the source provider's name. See Synchronization below. |
Globalizing Organization
Organizations are moved to the Admin page with the "Globalize" option, made available in all projects, and management is left to the Admin user.
To globalize the Organization, Move to Global (Move to Global) is selected from the menu at the end of the row.
Metadata
You can define user-defined key/value metadata entries on an organization. Organization metadata applies as defaults to every consumer in that organization; when the same key is also defined on a consumer, the consumer's value takes precedence.
These entries can be emitted as JWT claims or OAuth token response fields at token issuance, secret values are stored encrypted, and they are available to script policies. For field details, reserved names, and script access, see Consumer Metadata.
Synchronization
An organization created by LDAP or OIDC (Keycloak) group synchronization — see Credential Sync — carries a Synchronization section in its detail screen. This section is only shown for sync-managed organizations; an organization created directly in Apinizer does not have it.
| Field | Description |
|---|---|
| Source Type | How this organization was synchronized: LDAP OU, LDAP Group, or OIDC Group. |
| Source Name | The name of the specific provider record that synchronized this organization. |
| LDAP DN | Shown only for LDAP-sourced organizations; the record's full distinguished name in the directory. |
| Last Synchronized | The completion time of the provider's last synchronization run. |
If your account has identity management permission, the section also carries a Synchronize Now button. This triggers an immediate synchronization run for the organization's entire source provider — not just this one record — the same run that Synchronize Now on the central Synchronization screen triggers for that provider.
Consumers of an Organization
The organization detail page lists the consumers that belong to the organization in a Consumers card, next to the accounts, subscriptions and applications. The same card also appears at the bottom of the Members tab of the organization's edit page, under a Consumers heading, so both populations of an organization can be reviewed in one place. The list is loaded page by page from the server, so an organization with a large number of consumers does not slow the page down; type part of a consumer name in the search box to narrow it. Clicking a row, or its Open consumer link, opens that consumer's own page, where it is managed as usual. On the Admin page the card lists the organization's consumers from every project; inside a project it lists the consumers of that project together with the global ones. The project badge on a row shows which project a consumer belongs to.
A user with Identity Management → Manage permission also sees an Add consumer picker at the top of the card. Type part of a consumer name, pick the consumer and click Add consumer: the consumer is moved into this organization with the same action as Transferring a Consumer to Another Organization on its own page, so its API clients, access rows and issued tokens follow it and the gateways are updated. A consumer that already belongs to another organization is moved out of it. An organization that belongs to a project only accepts consumers of that project; a global organization on the Admin page accepts consumers from any project.
The same permission adds a Move to another organization action to every row of the card. It opens the same target picker as the consumer's own page: choose the organization and confirm, and the consumer leaves this organization together with its API clients, access rows and issued tokens. This is how a consumer is removed from an organization — a consumer always belongs to exactly one organization, so it is moved rather than detached. A user without the Manage permission sees the list read-only, with a note naming the permission that is missing.
The Members list on the same tab is a different population, and the tab keeps the two apart under their own headings: Portal accounts first, Consumers below. The members picker offers portal accounts and manages who may sign in to the Developer Portal on behalf of the organization; a portal account is a person who signs in, a consumer is an API identity that calls the gateway.
Deleting an Organization
An organization can only be deleted while it is empty. If any of the following still point at it, the deletion is refused and the organization is left untouched:
- sub-organizations that name it as their parent organization,
- consumers linked to it,
- portal applications belonging to it,
- portal accounts belonging to it.
The message shown on refusal names the categories of records that can block a delete; it does not say which of them apply to this organization or how many there are. Check the organization's sub-organizations, consumers, applications and portal accounts to find what is actually still attached, move or remove it, then try the delete again. Once nothing references the organization any more, it can be deleted. Deletion clears the organization link on the records that carried it and cannot be undone, which is why the organization name has to be typed into the confirmation dialog.
A consumer or a portal application can be moved to a different organization of the same project without deleting it — see Transferring a Consumer to Another Organization and Transferring an Application to Another Organization.
An organization managed by directory synchronization cannot be deleted manually at all, on any surface — the manager interface or the Management API both refuse it the same way. Records are no longer physically deleted by directory synchronization either: a stale organization is retired in place by its provider's synchronization run instead, which keeps it out of the way while preserving the bond its child consumers had with it. Permanent cleanup of retired records is planned as a separate maintenance capability. See Synchronization.
The rule is enforced on the server, not only in the interface. A deletion sent directly to the Management API for an organization that still has attached records, or for a sync-managed organization, is refused the same way the manager interface refuses it.
If a delete for the same organization is already being processed, a second attempt is refused with an HTTP 409 response until the first one finishes. See Concurrent Deletion if this persists long after nothing is actually running.