Portal Settings
General Settings
Portal Settings
| Field | Description | Usage in Portal Interface |
|---|---|---|
| Name | Used to identify the API Portal within the system. Used as a technical identifier. The portal is identified in system logs and reports. Required, unique field. e.g.: <companyName>-developer-portal | Technical identity within the portal; not directly visible in the interface but this value appears in logs and reports. |
| Display Name | A more understandable and user-friendly name is given to the portal. Used in marketing and communication. Helps users remember the portal more easily. Optional, user-friendly. e.g.: <companyName> API Developer Portal | Used as the title visible in the portal top menu and email templates. |
| Custom Portal URL | Used as the access address for the API Portal. Determined as the base address for all portal URLs in links in email notifications, API key activation links. Corporate domain is used. Must be in full URL format (http:// or https://) Example: https://apiportal.company.com | Base address for all portal links; buttons in registration/approval emails, redirects like “Forgot Password” are created according to this URL. |
| Default Language | Shown as the default language when the user first enters the API Portal. TR (Turkish): Portal opens in Turkish by default EN (English): Portal opens in English by default | Automatic language selection at portal entry; determines which options will be listed in the language switcher component. |
| Enable the English language option | When this feature is enabled, the English language option becomes active. Used as a language switcher in the portal. Determines whether English content will be displayed. Controls the multi-language feature. | Determines whether English content will be displayed. |
| Enable the Turkish language option | When this feature is enabled, the Turkish language option becomes active. Used as a language switcher in the portal. Determines whether Turkish content will be displayed. Controls the multi-language feature. | Determines whether Turkish content will be displayed. |
| Description | Defined as descriptive information for system administrators. Used to explain the purpose and scope of the portal. A note is left for other administrators. e.g.: This portal was created for our external partner companies to access our APIs. All APIs requiring access to customer data are published here. The portal is configured in accordance with GDPR and ISO 27001 standards. | Administrative note only; not displayed in the Portal user interface. |
Multi-Language Mode
Email Notifications
Automatic emails sent to users from the Portal are configured in this tab. Automatic emails are sent for user registration, approval, rejection, API subscription, etc.
Email Settings
| Field | Description |
|---|---|
| E-mail server | The address of the email server used by the API Portal to send emails. Predefined email server settings are selected. Selection is made from the Connection Config Email list. This setting includes SMTP server information. |
| Display Name | Determines the name with which email messages will be sent. Users understand where the email comes from by seeing this name |
| Sender Email | Specifies the address from which emails sent from the API Portal will be sent. For example, “[email protected]”. Emails are sent from this address. |
| Reply Email | Specifies the address that will be used when the user presses the “Reply” button. Example: “[email protected]” Must be a real support email. |
Email Templates
There are 8 different email types sent automatically from the Portal. Each can be customized separately. Templates and their usage purposes are explained in the table.| Template | When Sent | Impact on Portal | Email Triggering Steps | |
|---|---|---|---|---|
| Confirm Your Email Address | When a new user registers on the portal When the user needs to verify their email address | The account is not active until the user clicks the link in this email. Cannot log in to the portal without email confirmation (depending on setting) | STEP 1: User Registers, User clicks “Register” button on Portal, Fills registration form, Presses “Sign Up” button STEP 2: System Sends Email, “Confirm Email Address” email is automatically sent, Email reaches the address entered by the user, Contains special confirmation link STEP 3: User Receives Email, Subject: Your configured subject,Title: Your configured title, Body: Your configured content, Button: Your configured button text (e.g.: “Confirm My Email”) STEP 4: User Clicks Link, Clicks confirmation link/button in email, Redirected to Portal, Email address is verified STEP 5: Next Step (Depending on Setting), [If Auto Approve Account = ACTIVE], Account is automatically approved, Welcome email is sent, User can enter portal, [If Auto Approve Account = PASSIVE], Administrator approval is awaited,“Your account is being reviewed” message is shown, Welcome email is sent after administrator approval | Confirm Email |
| Welcome | When the user’s account is approved After manual approval by Administrator or in automatic approval case | Notifies the user that their account is active Says they can now log in to the Portal | STEP 1:User Has Confirmed Email, User clicked link in “Confirm Email Address” email, Email address verified STEP 2: Account Approved (Two Scenarios), [SCENARIO 1: Auto Approve Account = ACTIVE], Account is automatically approved,“Welcome” email is sent immediately [SCENARIO 2: Auto Approve Account = PASSIVE], Administrator receives notification, Administrator enters Manager, Goes to Portal Management → Developer Accounts section, Sees waiting user, Clicks [Approve] button, “Welcome” email is sent STEP 3: User Receives Email, Subject: Your configured subject,Title: Your configured title, Body: Your configured content, Button: Your configured button text (e.g.: “Go to Portal”) STEP 4: User Can Access Portal, Can now log in to portal, Can review APIs, Can register application | Welcome Email |
| Password Reset | When user clicks “Forgot Password” button When Administrator initiates password reset process for user | User sets new password by clicking link in this email Link becomes invalid after a certain period (security) | STEP 1: User Forgets Password, Clicks “Forgot Password?” link on Portal login page,Enters email address, Presses “Reset Password” button STEP 2: System Sends Email, “Reset Password” email is automatically sent, Email contains special reset link, Link is valid for certain period (e.g.: 24 hours) STEP 3: User Receives Email, Subject: Your configured subject, Title: Your configured title, Body: Your configured content, Button: Your configured button text (e.g.: “Reset My Password”) STEP 4: User Clicks Link, Clicks reset link/button in email, Redirected to password reset page on Portal, Enters new password (twice) STEP 5: Password Updated, New password saved, “Your password has been successfully updated” message, User can log in with new password | Reset Password Email |
| Account Access Rejected | When Administrator rejects user’s registration request When user is not deemed suitable in manual approval process | User cannot log in to portal Account is not created or deleted | STEP 1: User Has Registered and Confirmed Email, User registered on portal, Verified email address, Waiting for manual approval (Auto Approve Account = PASSIVE) STEP 2: Administrator Reviews Request, Administrator enters Manager, Goes to Portal Management → Developer Accounts section, Sees waiting users with “Pending Approval” filter, Reviews relevant user STEP 3: Administrator Rejects Request,[Reject] button is clicked, Enters rejection reason (optional), Confirms STEP 4: System Performs Operation, User account is deactivated or deleted, “Account Access Rejected” email is sent STEP 5: User Receives Email, Subject: Your configured subject, Title: Your configured title, Body: Your configured content. STEP 6: User Cannot Access Portal, Gets error when trying to log in, Sees “Your account is not active” message | Account Rejected Email |
| Account Access Revoked | When access of a previously active user is revoked When user is deactivated by Administrator In case of security or policy violation | User can no longer log in to portal Active sessions are closed API keys are deactivated | STEP 1: User Has Active Account, User was previously approved, Actively using Portal, Has access to APIs STEP 2: Revocation Reason Occurs, Security violation detected, Usage policy violated, Contract/membership ends, Manual administrator decision STEP 3: Administrator Revokes Access, Administrator enters Manager, Goes to Portal Management → Developer Accounts section, Finds relevant user, Selects [Revoke Access], Enters revocation reason (optional), Confirms STEP 4: System Performs Operation, User account is instantly deactivated, All active sessions are closed, API keys are deactivated, “Account Access Rejected” email is sent STEP 5: User Receives Email, Subject: Your configured subject, Title: Your configured title, Body: Your configured content. STEP 6: User Effects, Immediately logged out (if active session exists),Cannot log in again, API calls return 401 Unauthorized,All application registrations become passive | Account Revoked Email |
| App Registration Approved | When user’s app registration request to an API is approved After manual approval by Administrator or in automatic approval case | User can start using the API API keys become active User can access API documentation | STEP 1: User Wants to Subscribe to API, User logs in to portal,Reviews API catalog, Selects relevant API,Clicks “Subscribe” or “Register App” button STEP 2: Enters Application Information, Enters Application Name, Adds Description, Selects Plan (Free, Basic, Premium, etc.), Presses “Submit” button STEP 3: System Processes Request (Two Scenarios), [SCENARIO 1: Auto Approve API Subscribe = ACTIVE], Registration is automatically approved, API keys are instantly created, “App Registration Approved” email is sent [SCENARIO 2: Auto Approve API Subscribe = PASSIVE],Administrator receives notification, Administrator enters Manager,Goes to API Management → Subscriptions section, Sees waiting requests with “Pending Approval” filter,Reviews relevant request, Clicks [Approve] button, API keys are created, “App Registration Approved” email is sent STEP 4: User Receives Email, Subject: Your configured subject, Title: Your configured title, Body: Your configured content (enriched with variables), Button: Your configured button text (e.g.: “API Documentation”) STEP 5: User Starts Using API, Goes to “My Apps” section in Portal, Sees API keys (Client ID, Secret),Reads API documentation, Makes first API call,Tests and moves to production | App Approved Email |
| App Registration Rejected | When user’s app registration request to an API is rejected When Administrator deems request unsuitable | User cannot use that API API keys are not created User can apply again | STEP 1: User Has Made API Subscription Request, User subscribed to API, Entered application information, Waiting for manual approval (Auto Approve API Subscribe = PASSIVE) STEP 2: Administrator Reviews Request, Administrator enters Manager, Goes to API Management → Subscriptions section,Sees waiting requests with “Pending Approval” filter STEP 3: Administrator Rejects Request, Selects [Reject], Enters rejection reason (optional, not shown to user), Confirms STEP 4: System Performs Operation, Subscription request is marked as rejected, API keys are not created, “App Registration Rejected” email is sent STEP 5: User Receives Email, Subject: Your configured subject, Title: Your configured title, Body: Your configured content, Button: Log In STEP 6: User Options, Sees request rejected in portal, Can try again with different plan,Can contact support, Can subscribe to another API | App Rejected Email |
| App Registration Revoked | When a previously approved app registration is revoked In case of API usage policy violation When access is removed by Administrator | User’s API access is cut off Existing API keys are deactivated API calls fail (401 Unauthorized) | STEP 1: User Has Active Subscription, User’s app registration was previously approved, Actively using API,API keys are working STEP 2: Revocation Reason Occurs, API usage policy violation, Rate limit overruns (continuous), Payment issues (in paid plans), Security violation detected, Abuse detected, Contract termination, Manual administrator decision STEP 3: Administrator Revokes Subscription, Administrator enters Manager, Goes to API Management → Subscriptions section, Finds relevant subscription in Active subscriptions list, Selects [Revoke], Enters revocation reason (optional), Confirms STEP 4: System Performs Operation, Subscription is instantly revoked, All API keys are deactivated, Rate limiter keys are cleared, “App Registration Revoked” email is sent STEP 5: User Receives Email, Subject: Your configured subject, Title: Your configured title, Body: Your configured content, Button: Log In STEP 6: User and API Effects, API calls fail from that moment, HTTP 401 Unauthorized or 403 Forbidden returned, User sees “Revoked” status in portal, “Access Revoked” warning on Application page | App Revoked Email |
Email Template Images
Confirm Email
Welcome Email
Reset Password Email
Account Rejected Email
Account Revoked Email
App Approved Email
App Rejected Email
App Revoked Email
Email Template
- If “{{developer_fullname}}” is used in the email template → The name of the user who will receive the notification is automatically written in that place. This way, personalized addressing is provided in sent emails
- API product name
- Developer’s application name
- If “{{api_name}}” is used in the email template → The name of the API product related to the notification is automatically written in that place.
- If “{{application_name}}” is used in the email template → The name of the application related to the notification is automatically written in that place.
| Field | Description |
|---|---|
| Email notification active | Determines whether email notification is active. If active, email is sent to the user. This setting can be customized for each email. |
| Subject | Specifies the text that will appear in the subject line of the email. Usually a title that summarizes the email content. |
| Title | Specifies the title of the email content. The title text visible to the user in the email. |
| Content | Email content. Contains the detailed text of the message to be sent to the user. Can be personalized with placeholders in email templates (e.g., {{developer_fullname}}). |
| Button label | Specifies the text that will appear on the button in the email content. Users perform actions by clicking this button. For example, “Confirm your email address”. |
Security
Privacy settings to be used on the API Developer Portal side are managed through this screen.Security Settings
| Field | Description | Usage in Portal Interface |
|---|---|---|
| Activate developers to create their own accounts | Security tab → Enable Account Register Used to open or close new user registration on Portal, control self-service registration feature. When active Users can register on portal themselves, “Sign Up” button is visible, Registration form is accessible. | Determines visibility of “Sign Up/Register” button on Portal login page; if passive, self-signup is closed. |
| Auto Approve Account/Developers | Security tab → Auto Approve Account Used to automate or make manual the user approval process, set security level, provide access control. When active user is automatically approved when registered, Can enter portal immediately after email confirmation, No administrator intervention needed, Welcome email is automatically sent. | Determines whether users who confirm email after registration will automatically become active; if passive, manual approval from Manager is required. |
| Allow Organization Administrator to Manage their own Accounts | Security tab → Organization Manager Account Manage Controls whether Organization Manager role assignment is available when creating new registration through Account/Developer menu. This assignment allows account/developer to create their own account/developer on API Portal side. When active only portal administrators (admin) can manage users, organization administrators can only see their own accounts, central control is provided. | Controls whether organization administrators can manage users/accounts within Portal (affects permissions on Portal → Accounts screen). |
| Auto allow accounts to subscribe to APIs | Security tab → Auto Approve API Subscribe When a developer or account registers on the API portal, subscription permission to APIs is automatically granted. That is, there is no need for manual approval by an administrator. When active when user makes app registration to an API, it is automatically approved, API keys are immediately created and activated, user can start using API instantly, app Registration Approved email is automatically sent. | Enables automatic approval of plan and immediate definition of API keys when user Subscribe/Register App; if passive, manual approval flow works in Manager. |
| Allow Accounts to Manage their own Credentials | Security tab → Enable Credential Manage Used to give or not give users permission to manage their own API keys, limit credential management due to security policy. When active users can see their own API keys, can create new credentials, can delete or renew existing credentials, can see API secrets. | Opens/closes developers’ permission to generate, recreate, or delete client ID/secret in My Apps section in Portal. |
Features
Features to be used on the API Developer Portal side are managed through this screen.Features Settings
| Field | Description |
|---|---|
| Activate the How to use menu | Features tab → Enable How It Works How to use menu is visible to users. Used to show or hide a page that will guide users in Portal. When active “How It Works” / “Nasıl Çalışır” link appears in menu, How It Works HTML content defined in Portal Appearance is shown, users can access this page. |
| Activate the Test Tools menu | Features tab → Enable Test Tools Test tools menu is visible to users. Used to enable users to test APIs from portal, provide Swagger UI-like test interface. When active “Try It” button appears in API documentation, users can make API calls from portal, Request/Response preview becomes active. |
| Define Your API Portal Integration with Jira | Features tab → Enable Jira Integration Jira Integration menu is visible. Used to provide feature to create Jira tickets from portal, automate support process. When active Users can open Jira tickets from portal, “Report Issue” or “Request Feature” buttons appear, Jira integration works. |
| Enable MCP (Model Context Protocol) Feature | Features tab → Enable MCP AI assistants and tools can access and use the system’s context data. When active MCP features can be used. |
| Allow accounts to view their Analytics information | Features tab → Enable Analytics Accounts view their own analytics information. Used to show API usage statistics to users, activate Dashboards. When active Analytics dashboard is visible to users, API call statistics are shown, Charts and reports are active. |
| Define your API Performance Metrics | Features tab → Performance Metrics In this section, configurations are made for the following fields; Max Acceptable Value For Good Performance: The maximum value indicating that the response time of a request within the expected time is normal is entered. Min Acceptable Value For Bad Performance: The minimum value indicating that the response time of a request within the expected time is abnormal is entered. |
Legal
Legal settings to be used on the API Developer Portal side are managed through this screen.Legal Settings
| Field | Description |
|---|---|
| Define your API Portal Legal Agreement | A document specifying the terms of use, privacy policy, and legal obligations valid when using the API Portal. Prepare your PDF file (Terms of Service, Privacy Policy, etc.) Click “Upload PDF” button Select and upload file Uploaded file will be visible and you can preview with “Open” |
SEO
SEO settings to be used on the API Developer Portal side are managed through this screen.
SEO Settings
| Field | Description |
|---|---|
| SEO robots.txt | A text file that tells search engine bots which pages they can crawl and index on your site or which pages they cannot access. This way, site owners enable search engines to crawl their sites more efficiently and in a controlled manner. |