API Portal Settings

Manages basic configurations, security settings, email notifications, features, and legal regulations of Apinizer API Developer Portal. It is the central settings page that directly affects the portal’s general behavior and user experience.

Portal Settings (API Portal Settings) controls the portal’s basic settings, behaviors, and content pages. This page manages general settings, email notifications, security settings, features, legal regulations, portal content management (Home Page, Footer, How It Works, Pending Page, Navigation Menu), SEO settings, Login Log (login audit database and connector configuration), and Danger Zone.

Portal Appearance controls visual elements (logo, colors, font).

General Settings

The portal’s basic configuration settings are made in this section.

Portal Settings General

Fields used for Portal Settings configuration are shown in the table below.

Field	Description	Usage in Portal Interface
Name	Used to identify API Portal within the system. Used as a technical identifier. Portal is identified in system logs and reports. Required, unique field. Example: <companyName>-developer-portal	Technical identity within portal; not directly visible in interface but this value is included in logs and reports.
Display Name	A more understandable and user-friendly name is given to the portal. Used in marketing and communication. Enables users to remember the portal more easily. Optional, user-friendly. Example: <companyName> API Developer Portal	Used as the title visible in portal top menu and email templates.
Custom Portal URL	Used as the access address to API Portal. Determined as the base address of 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 of all portal links; buttons in registration/approval email, redirects like “Forgot Password” are created according to this URL.
Default Language	Shown as the default language when the user first enters API Portal. You can select any language defined in the system (TR, EN, DE, FR, ES, etc.). Portal opens in the selected language and users can switch to their preferred language using the language switcher.	Automatic language selection at portal entry; determines which options will be listed in the language switcher component.
Language Options	Determines which languages will be available to users in the portal. You can select as many languages as you want from all languages defined in the system (Turkish, English, German, French, Spanish, etc.). Each language can be enabled separately. Enabled languages appear as a language switcher in the portal and users can switch between these languages. Controls the multi-language feature.	Determines whether content in enabled languages will be shown. When multiple languages are enabled, the portal switches to multilanguage mode.
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. Example: This portal was created for our external partner companies to access our APIs. All APIs requiring customer data access are published here. Portal is configured in accordance with GDPR and ISO 27001 standards.	Administrative note only; not shown in Portal user interface.

When multiple language options are enabled in Portal settings, the system automatically switches to Multilanguage mode.

If the Multilanguage feature is activated from Portal Settings, Interface and form fields are displayed in all enabled languages, and separate data entry can be made for each language. The system is not limited to Turkish and English only; it supports all languages defined in the system (German, French, Spanish, Italian, etc.).

Important: Content entry is required for each language. If content is not entered for an enabled language, pages may appear empty in that language.

Email Notifications

Automatic emails sent to users from the portal are configured in this tab. Automatic emails are sent for operations such as user registration, approval, rejection, API subscription.

Email Settings

Fields used for Email Settings are shown in the table below.

Field	Description
E-mail server	The address of the email server used by 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 came from by seeing this name
Sender Email	Specifies the address from which emails sent from API Portal will be sent. For example, “[e-mail]”. Emails are sent from this address.
Reply Email	Specifies the address that will be used when the user presses the “Reply” button. Example: “[e-mail]” Must be a real support email.

Email Templates

There are 8 different email types sent automatically from the portal. Each can be customized separately.

Confirm Your Email Address

When Sent:

• When a new user registers on the portal
• When the user needs to verify their email address

Effect on Portal: The account does not become active until the user clicks the link in this email. Portal login cannot be done without email confirmation (depending on setting).

Email Triggering Steps:

1. User Registers

   Clicks “Register” button on portal, Fills registration form, Presses “Sign Up” button

2. System Sends Email

   “Confirm Email Address” email is automatically sent, Email reaches the address entered by the user, Contains special confirmation link

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”)

4. User Clicks Link

   Clicks confirmation link/button in email, Redirected to portal, Email address is verified

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 approves

Welcome

When Sent:

• When the user’s account is approved
• After manual approval by administrator or in automatic approval situation

Effect on Portal: Notifies the user that their account is active. Tells them they can now log in to the portal.

Email Triggering Steps:

1. User Has Confirmed Email

   User has clicked the link in “Confirm Email Address” email, Email address has been verified

2. Account is 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 pending user, Clicks [Approve] button, “Welcome” email is sent

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”)

4. User Can Access Portal

   Can now log in to portal, Can review APIs, Can register application

Password Reset

When Sent:

• When user clicks “Forgot Password” button
• When administrator initiates password reset process for user

Effect on Portal: User sets a new password by clicking the link in this email. Link becomes invalid after a certain period (security).

Email Triggering Steps:

1. User Forgets Password

   Clicks “Forgot Password?” link on portal login page, Enters email address, Presses “Reset Password” button

2. System Sends Email

   “Reset Password” email is automatically sent, Email contains special reset link, Link is valid for a certain period (e.g., 24 hours)

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”)

4. User Clicks Link

   Clicks reset link/button in email, Redirected to password reset page on portal, Enters new password (twice)

5. Password is Updated

   New password is saved, “Your password has been successfully updated” message, User can log in with new password

Account Access Rejected

When Sent:

• When administrator rejects user’s registration request
• When user is not deemed suitable in manual approval process

Effect on Portal: User cannot log in to portal. Account is not created or is deleted.

Email Triggering Steps:

1. User Has Registered and Confirmed Email

   User has registered on portal, Has verified email address, Waiting for manual approval (Auto Approve Account = PASSIVE)

2. Administrator Reviews Request

   Administrator enters Manager, Goes to Portal Management → Developer Accounts section, Sees pending users with “Pending Approval” filter, Reviews relevant user

3. Administrator Rejects Request

   Clicks [Reject] button, Enters rejection reason if desired (optional), Confirms

4. System Performs Operation

   User account is deactivated or deleted, “Account Access Rejected” email is sent

5. User Receives Email

   Subject: Your configured subject, Title: Your configured title, Body: Your configured content

6. User Cannot Access Portal

   Gets error if tries to log in, Sees “Your account is not active” message

Account Access Cancelled

When Sent:

• When access of a previously active user is cancelled
• When user is disabled by administrator
• In case of security or policy violation

Effect on Portal: User can no longer log in to portal. Existing sessions are closed. API keys are disabled.

Email Triggering Steps:

1. User Has Active Account

   User was previously approved, Is actively using Portal, Has API access

2. Cancellation Reason Occurs

   Security violation is detected, Usage policy is violated, Contract/membership ends, Manual administrator decision

3. Administrator Cancels Access

   Administrator enters Manager, Goes to Portal Management → Developer Accounts section, Finds relevant user, Selects [Revoke Access], Enters cancellation reason (optional), Confirms

4. System Performs Operation

   User account is instantly disabled, All active sessions are closed, API keys are deactivated, “Account Access Rejected” email is sent

5. User Receives Email

   Subject: Your configured subject, Title: Your configured title, Body: Your configured content

6. User Effects

   Immediately logged out (if active session exists), Cannot log in again, API calls return 401 Unauthorized, All application registrations become passive

App Registration Approved

When Sent:

• When user’s app registration request for an API is approved
• When administrator gives manual approval or in automatic approval situation

Effect on Portal: User can start using the API. API keys become active. User can access API documentation.

Email Triggering Steps:

1. User Wants to Subscribe to API

   User logs in to portal, Reviews API catalog, Selects relevant API, Clicks “Subscribe” or “Register App” button

2. Enters Application Information

   Enters Application Name, Adds Description, Selects Plan (Free, Basic, Premium, etc.), Presses “Submit” button

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 pending requests with “Pending Approval” filter, Reviews relevant request, Clicks [Approve] button, API keys are created, “App Registration Approved” email is sent

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”)

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 takes to production environment

App Registration Rejected

When Sent:

• When user’s app registration request for an API is rejected
• When administrator does not deem the request suitable

Effect on Portal: User cannot use that API. API keys are not created. User can apply again.

Email Triggering Steps:

1. User Has Made Subscription Request for API

   User has subscribed to API, Has entered application information, Waiting for manual approval (Auto Approve API Subscribe = PASSIVE)

2. Administrator Reviews Request

   Administrator enters Manager, Goes to API Management → Subscriptions section, Sees pending requests with “Pending Approval” filter

3. Administrator Rejects Request

   Selects [Reject], Enters rejection reason (optional, not shown to user), Confirms

4. System Performs Operation

   Subscription request is marked as rejected, API keys are not created, “App Registration Rejected” email is sent

5. User Receives Email

   Subject: Your configured subject, Title: Your configured title, Body: Your configured content, Button: Log In

6. User Options

   Sees request was rejected in portal, Can try again with a different plan, Can contact support, Can subscribe to another API

App Registration Revoked

When Sent:

• When a previously approved app registration is revoked
• In case of API usage policy violation
• When access is removed by administrator

Effect on Portal: User’s API access is cut off. Existing API keys are disabled. API calls fail (401 Unauthorized).

Email Triggering Steps:

1. User Has Active Subscription

   User’s app registration was previously approved, Is actively using API, API keys are working

2. Revocation Reason Occurs

   API usage policy violation, Rate limit violations (continuous), Payment issues (in paid plans), Security violation is detected, Abuse is detected, Contract termination, Manual administrator decision

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

4. System Performs Operation

   Subscription is instantly revoked, All API keys are disabled, Rate limiter keys are cleared, “App Registration Revoked” email is sent

5. User Receives Email

   Subject: Your configured subject, Title: Your configured title, Body: Your configured content, Button: Log In

6. User and API Effects

   API calls fail from that moment, Returns HTTP 401 Unauthorized or 403 Forbidden, User sees “Revoked” status in portal, “Access Revoked” warning on Application page

The template found in the image below should be used for Confirm email address, Welcome, Account Access Rejected, Account Access Cancelled, App Registration approved, App Registration Rejected, App Registration Revoked, and Password Reset emails.

Email Template

In All Email Templates:

{{developer_fullname}}

• 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

In App Registration Approved, App Registration Approved, and App Registration Revoked Email Templates:

{{api_name}} - API product name

{{application_name}} - Developer’s application name

• If {{api_name}} is used in the email template → The name of the API product that the notification is related to is automatically written in that place.
• If {{application_name}} is used in the email template → The name of the application that the notification is related to is automatically written in that place.

This way, the user sees which API the notification they received is for. If they have multiple applications, they can easily understand which application the notification is about.

Fields used for Email Settings configuration are shown in the table below.

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 email’s subject line. Usually a heading 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 operations 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

Fields used for Security Settings configuration are shown in the table below.

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 the portal, control self-service registration feature. When active, Users can register themselves on the portal, “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, adjust 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. Manages whether there is the possibility of assigning Organization Manager role when creating new registration through Account/Developer menu. This assignment allows the account/developer to create their own account/developer on the API Portal side. When active, only portal administrators (admin) can do user management, organization administrators can only see their own accounts, centralized 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 given. That is, there is no need for manual approval by an administrator. When active, when user registers app for an API, it is automatically approved, API keys are immediately created and become active, user can instantly start using the API, app Registration Approved email is automatically sent.	Ensures that when user Subscribe/Register App, the plan is automatically approved and API keys are immediately defined; in 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, create new credentials, delete or renew existing credentials, 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

Fields used for Feature Settings configuration are shown in the table below.

Field	Description
Activate the How to use menu	Features tab → Enable How It Works. How to use menu becomes visible to users. Used to show or hide a page that will guide users on the 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 becomes visible to users. Used to enable users to test APIs through the portal, provide Swagger UI-like test interface. When active, “Try It” button appears in API documentation, users can make API calls through portal, Request/Response preview becomes active.
Define Your API Portal Integration with Jira	Features tab → Enable Jira Integration. Jira Integration menu becomes visible. Used to provide ability to create Jira tickets through 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 becomes visible to users, API call statistics are shown, Charts and reports are in active state.
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 a request’s response time within expected time is normal is entered. Min Acceptable Value For Bad Performance: The minimum value indicating that a request’s response time within 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

The field used for Legal Settings configuration is shown in the table below.

Field	Description
Define your API Portal Legal Agreement	A document specifying the terms of use, privacy policy, and legal obligations valid when using API Portal. 1. Prepare your PDF file (Terms of Service, Privacy Policy, etc.) 2. Click “Upload PDF” button 3. Select and upload the file 4. 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

The field used for SEO Settings configuration is shown in the table below.

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.

Portal Content Management

In the API Portal Settings page, you can manage the portal’s content pages. In this section, you can configure settings for the home page, footer, “How It Works” page, pending page, and navigation menu.

Portal Content Pages Management

Overview of Portal Pages

When each portal is created, the system automatically creates a set of default pages. These pages provide the portal’s basic functionality and can be viewed by users.

Default Portal Pages:

Page Type	Description	Access Status	Default Content
Portal Home	The main page that users see when they first enter the portal	Public (Open to everyone)	Default welcome message and portal introduction
Footer	Footer area visible at the bottom of the portal	Public (Visible on all pages)	Default footer content (empty or minimal)
How It Works	Portal usage guide page	Public (if feature is active)	Default usage guide content
Pending Page	Page for users waiting for account approval	Private (Only users in waiting status)	Default waiting message
Login Page	User login page	Public (Users not logged in)	Automatically created by system
Register Page	User registration page	Public (if registration permission exists)	Automatically created by system
API Catalog	Page listing published APIs	Public (Logged in users)	Automatically created by system
My Apps	Page where users manage their applications	Private (Only logged in users)	Automatically created by system

Page Access Statuses

Portal pages are categorized according to their access status:

Public Pages

Public pages can be viewed by everyone, including users who are not logged in:

• Portal Home: Home page is open to everyone
• Footer: Visible on all pages
• How It Works: Open to everyone if feature is active
• Login Page: Login page is open to everyone
• Register Page: Open to everyone if registration permission exists
• API Catalog: Published APIs are visible to everyone (login may be required for details)

Public pages are critical for portal promotion and user acquisition.

Private Pages

Private pages can only be viewed by logged in and authorized users:

• My Apps: Only logged in users can see their own applications
• Analytics: Only logged in users can see their own statistics
• API Details: Some API details are only open to subscribed users
• Pending Page: Only users in waiting status can see it

Private pages require user authentication. Users who are not logged in cannot access these pages.

Conditional Pages

Conditional pages are shown or hidden based on certain conditions:

• How It Works: Visible if “How It Works” is active in Portal Settings → Features
• Test Tools: Visible if “Test Tools” is active in Portal Settings → Features
• Analytics: Visible if “Analytics” is active in Portal Settings → Features and user is logged in
• Jira Integration: Visible if “Jira Integration” is active in Portal Settings → Features

Conditional pages are controlled by the portal administrator through feature settings.

Portal Pages Working Logic

1. Page Creation and Management:

Pages for each portal are created in two ways:

Automatically Created by System

Automatically Created Pages:

• Created automatically by the system when portal is created
• Come with default content
• Cannot be deleted or disabled
• Only their content can be edited

Examples:

• Login Page
• Register Page
• API Catalog
• My Apps

These pages provide the portal’s basic functionality and are managed by the system.

Managed by Administrator

Administrator-Managed Pages:

• Managed from Portal Settings → Portal Content Management section
• Content can be fully customized
• HTML format content can be added
• Multi-language support available

Examples:

• Portal Home
• Footer
• How It Works
• Pending Page

The content of these pages can be customized by the portal administrator.

2. Page Content Management:

Portal page content is managed in the following ways:

Management Method	Description	Pages Used
HTML Editor	Creating content with HTML code	Portal Home, Footer, How It Works, Pending Page
System Management	Content automatically created by system	Login, Register, API Catalog, My Apps
Dynamic Content	Content from APIs and database	API Catalog, My Apps, Analytics

3. Multi-Language Support:

Portal pages offer multi-language support:

• Default Language: Determined from Portal Settings → General Settings (can be selected from all languages defined in the system)
• Language Options: Any number of languages can be activated from all languages defined in the system (Turkish, English, German, French, Spanish, Italian, etc.)
• Content Management: Separate content can be prepared for each language
• Automatic Redirect: System shows appropriate content based on user’s language preference

When multi-language feature is active, separate content can be prepared for Portal Home, Footer, How It Works, and Pending Page in all enabled languages. The system is not limited to Turkish and English only; it supports all languages defined in the system.

4. Page Visibility Control:

Page visibility is controlled based on the following factors:

• Portal Settings: Pages can be activated/deactivated from feature settings
• User Status: Based on logged in/not logged in user status
• User Roles: Based on user role (Admin, Developer, Guest)
• API Subscription Status: Some pages are only open to subscribed users

Page Management Operations

You can perform the following operations to manage portal pages:

Content Editing

Edit Portal Home, Footer, How It Works, and Pending Page content with HTML editor

Multi-Language Management

Prepare content in all enabled languages for each page (Turkish, English, German, French, etc.)

Preview

Preview changes before saving

Visibility Control

Control page visibility from feature settings

Portal Home Page

The portal home page is the page that users see when they first enter the portal. This page contains portal introduction texts, guiding descriptions, links, or visual content.

Portal Home Page Features:

Feature	Description
Access Status	Public (Open to everyone) - Everyone including users not logged in can access
Default Content	Comes with default welcome message and portal introduction when portal is created
Content Format	HTML format content can be added (headings, paragraphs, lists, links, images)
Multi-Language	Content can be prepared in all enabled languages (Turkish, English, German, French, Spanish, etc.)
Preview	Changes can be previewed before saving
URL	Portal main URL (e.g., https://portal.company.com/)

Portal Home Page Settings

Default Home Page Content:

When the portal is created, the home page comes with default content:

• Welcome Title: “Welcome to [Portal Name]”
• Short Description: General information about the portal
• Action Cards:
  • “How It Works?” - Redirects to How It Works page
  • “Discover Our APIs” - Redirects to API catalog
  • “Register” - Redirects to registration page
  • “Contact Us” - Redirects to contact page

Default content can be fully customized by the portal administrator. You can add any content you want with the HTML editor.

1. Go to Portal Home Page Tab

   • Click on “Portal Home” or “Home Page” tab in API Portal Settings page
   • Home page content editing screen opens
2. Content Editing

   HTML editor is located on the left. In this editor you can:

   • Write HTML code
   • Use Markdown format
   • Add headings, paragraphs, lists, links
   • Add images and tables

   The HTML editor offers rich text editing features. You can switch between code view and visual view.
3. Multi-Language Support

   If multi-language is active in portal settings, you will see a separate tab for each enabled language:

   • Portal Home (TR): Turkish content area
   • Portal Home (EN): English content area
   • Portal Home (DE): German content area (if enabled)
   • Portal Home (FR): French content area (if enabled)
   • And other enabled languages…

   You can prepare separate content for each language. The system shows appropriate content based on user’s language preference.

4. Preview

   “Preview” section is located on the right:

   • You can see in real-time how your HTML content will appear on the portal
   • Preview automatically updates as you make changes
   • You can check mobile and desktop views
5. Saving Content

   • After preparing the content, click the “Save” button at the top of the page
   • Changes are saved and immediately reflected on the portal home page
   • Portal users will see the new content when they refresh the page

Home Page Content Examples:

The home page usually contains the following content:

• Portal welcome message and title
• Short description about the portal
• Action cards like “How It Works?”, “Discover Our APIs”, “Register”, “Contact Us”
• Featured APIs or features
• Corporate information and links
• Images, banners, or video content
• Statistics or success stories

Home Page Access Logic:

Home page access works as follows:

1. Users Not Logged In:

   • Can view the home page
   • Can get information about the portal
   • Can register by clicking “Register” button
   • Can see API catalog with “Discover Our APIs” (only published APIs)

2. Logged In Users:

   • Can view the home page
   • Can access “My Apps” menu
   • Can subscribe to APIs
   • Can access Analytics page (if feature is active)

3. Administrators:

   • Can view the home page
   • Can access all features
   • Can perform portal management operations

Since home page content is in HTML format, you can also use CSS styles and JavaScript code. However, complex scripts may affect portal performance. For security reasons, only use scripts you trust.

Footer

Footer is the content area displayed at the bottom of the portal. It usually contains contact information, legal texts, copyright statements, or corporate links.

Footer Features:

Feature	Description
Access Status	Public (Open to everyone) - Visible on all pages
Default Content	Comes with default footer content when portal is created (usually empty or minimal)
Visibility	Visible at the bottom of all portal pages (Home, APIs, How It Works, etc.)
Content Format	HTML format content can be added (tables, lists, links, images)
Multi-Language	Content can be prepared in all enabled languages (Turkish, English, German, French, Spanish, etc.)
Script Support	JavaScript code can be executed (e.g., live chat widgets)

Default Footer Content:

When the portal is created, the footer comes empty or with minimal content by default. It needs to be customized by the administrator.

Footer Visibility Logic:

Footer is visible on all portal pages:

• Home page
• API catalog
• API detail pages
• How It Works page
• Login and Register pages
• User panel pages (My Apps, Analytics)

Footer content is displayed consistently on all portal pages. This way, users can access contact information and legal links on every page.

1. Go to Footer Tab

   • Click on “Footer” or “Footer” tab in API Portal Settings page
   • Footer content editing screen opens
2. Editing Footer Content

   Prepare footer content in the HTML editor on the left:

   • Contact information (address, phone, email)
   • Social media links and icons
   • Legal texts (Terms of Service, Privacy Policy)
   • Copyright information
   • Corporate links
   • Logo or images

   Since footer content is in HTML format, you can add tables, lists, and links.
3. Multi-Language Support

   If multi-language is active:

   • Footer (TR): Turkish footer content
   • Footer (EN): English footer content
   • Footer (DE): German footer content (if enabled)
   • Footer (FR): French footer content (if enabled)
   • And other enabled languages…

   You can prepare separate footer content for each enabled language.

4. Preview and Save

   • You can preview how the footer will appear on the portal on the right
   • After making changes, click the “Save” button
   • Footer content is immediately reflected at the bottom of the portal

Footer Content Examples:

Footer usually contains the following information:

• Company name and logo
• Contact information (address, phone, email)
• Social media icons (LinkedIn, Twitter, GitHub, etc.)
• Quick links (About Us, Support, Documentation)
• Legal links (Terms of Service, Privacy Policy)
• Copyright information (© 2024 Company Name)

If you use <script> tags in footer content, these scripts are executed safely. However, for security reasons, only use scripts you trust.

How It Works

The “How It Works” page is an informative page that explains the system’s general operation, API access process, or registration/step-by-step usage guide to portal users.

How It Works Features:

Feature	Description
Access Status	Public (Open to everyone) - Everyone can access if feature is active
Default Content	Comes with default usage guide content when portal is created
Visibility Control	Visible if “How It Works” is active in Portal Settings → Features
Menu Location	Appears as “How It Works?” or “Nasıl Çalışır?” link in portal top menu
Content Format	HTML format content can be added (step-by-step guide, icons, lists)
Multi-Language	Content can be prepared in all enabled languages (Turkish, English, German, French, Spanish, etc.)
URL	Portal URL + /how-it-works (e.g., https://portal.company.com/how-it-works)

Default How It Works Content:

When the portal is created, the How It Works page comes with default content:

• Title: “How It Works” or “Nasıl Çalışır”
• General Description: General information about portal usage
• Step-by-Step Guide: Basic usage steps
• API Access Process: How to access APIs
• Registration Process: How to register on the portal

The How It Works page can be fully customized by the portal administrator. You can add step-by-step guides, images, icons, and examples to the content.

How It Works Visibility Logic:

The visibility of the How It Works page depends on the following conditions:

1. If Feature is Active:

   • Portal Settings → Features → “How It Works” is active
   • “How It Works?” link appears in portal top menu
   • Everyone (logged in/not logged in) can access the page

2. If Feature is Passive:

   • Link does not appear in portal top menu
   • Users cannot access even if page content is prepared
   • Direct URL access may not be possible

For the How It Works page to be visible, the “How It Works” feature must be activated in Portal Settings → Features section.

1. Go to How It Works Tab

   • Click on “How It Works” or “How It Works” tab in API Portal Settings page
   • How It Works content editing screen opens
2. Preparing Content

   Prepare content in the HTML editor on the left:

   • Step-by-step usage guide
   • API access process description
   • Registration and account creation steps
   • API usage examples
   • Frequently asked questions
   • Icons, numbered lists, and images

   The How It Works page is prepared to enhance user experience and explain portal usage.
3. Multi-Language Support

   If multi-language is active:

   • How It Works (TR): Turkish content
   • How It Works (EN): English content
   • How It Works (DE): German content (if enabled)
   • How It Works (FR): French content (if enabled)
   • And other enabled languages…

   You can prepare separate content for each enabled language.

4. Appearance in Portal Menu

   • The How It Works page appears as “How It Works?” or “Nasıl Çalışır?” link in portal top menu
   • When this link is clicked, the content you prepared is shown
   • For it to appear in the menu, the “How It Works” feature must be active in Portal Settings → Features section
5. Saving

   • After preparing the content, click the “Save” button
   • Changes are saved and the page becomes accessible from the portal menu

How It Works Content Examples:

This page usually contains the following information:

• Steps to register on the portal
• Process of discovering and reviewing APIs
• Application registration and API subscription process
• Getting and using API keys
• Steps to make API calls
• Troubleshooting and support information

Pending Page

The Pending Page is a waiting page that users view while waiting for account approval or until a certain operation is completed. This page informs users about their status and explains what they need to do.

Pending Page Features:

Feature	Description
Access Status	Private - Only users in waiting status can see it
Default Content	Comes with default waiting message when portal is created
Visibility	Automatically shown only for users in certain statuses
Content Format	HTML format content can be added (messages, instructions, images)
Multi-Language	Content can be prepared in all enabled languages (Turkish, English, German, French, Spanish, etc.)
Automatic Redirect	System automatically redirects to this page based on user status

Default Pending Page Content:

When the portal is created, the Pending Page comes with default content:

• Title: “Your Account is Pending Approval” or “Hesabınız Onay Bekliyor”
• Description: Information about account approval process
• Waiting Message: “Your account is being reviewed. You will be notified once it’s approved.”
• Contact Information: Instructions to contact support team

Pending Page content should help users understand their status and know what they need to do. A reassuring and informative tone should be used.

Pending Page Display Scenarios:

The Pending Page is automatically displayed in the following situations:

Waiting for Account Approval

Scenario: User has registered and confirmed email, but account has not yet been approved by administrator.

Conditions:

• Portal Settings → Security → “Auto Approve Account” = PASSIVE
• User has confirmed email address
• Administrator has not yet approved the account

User Experience:

• When user tries to log in, Pending Page is displayed
• “Your account is pending approval” message is shown
• User cannot access portal content

Waiting for API Subscription Approval

Scenario: User has subscribed to an API, but subscription has not yet been approved.

Conditions:

• Portal Settings → Security → “Auto Approve API Subscribe” = PASSIVE
• User has subscribed to API
• Administrator has not yet approved the subscription

User Experience:

• When user goes to API detail page, Pending Page may be displayed
• “Your subscription is pending approval” message is shown
• User cannot use the API

Account Suspension

Scenario: User account has been temporarily suspended.

Conditions:

• Administrator has suspended user account
• Account is not completely deleted, only temporarily disabled

User Experience:

• When user tries to log in, Pending Page is displayed
• “Your account is temporarily suspended” message is shown
• Contact information is provided

Pending Page content should help users clearly understand their status. Ambiguous messages negatively affect user experience.

1. Go to Pending Page Tab

   • Click on “Pending Page” or “Pending Page” tab in API Portal Settings page
   • Pending Page content editing screen opens
2. Preparing Waiting Page Content

   Prepare content in the HTML editor on the left:

   • Message informing user about status
   • Instructions explaining what they need to do
   • Information about waiting period
   • Contact information (for questions)
   • Visual elements (icons, animations)

   Pending Page is the page users view while waiting for account approval or during manual approval process.
3. Multi-Language Support

   If multi-language is active:

   • Pending Page (TR): Turkish content
   • Pending Page (EN): English content
   • Pending Page (DE): German content (if enabled)
   • Pending Page (FR): French content (if enabled)
   • And other enabled languages…

   You can prepare separate content for each enabled language.

4. When It Is Displayed

   Pending Page is displayed in the following situations:

   • User has registered and confirmed email, but account has not yet been approved (Auto Approve Account = PASSIVE)
   • User has subscribed to API, but subscription has not yet been approved (Auto Approve API Subscribe = PASSIVE)
   • User account has been suspended or temporarily disabled

   Pending Page content should help users understand their status and know what they need to do.
5. Saving

   • After preparing the content, click the “Save” button
   • Changes are saved and users in waiting status will see this page

Pending Page Content Examples:

This page usually contains the following information:

• “Your account is pending approval” message
• Information about approval process
• Estimated waiting time
• Contact information (support team for questions)
• Instructions for status check
• Reassuring messages

Navigation Menu

Navigation Menu allows you to manage the menu structure visible at the top of the portal. You can control which pages appear in this menu, their order, and visibility.

Navigation Menu Features:

Feature	Description
Location	At the top of the portal, between logo and user menu
Default Menu Items	Comes with default menu items when portal is created
Dynamic Menu	Menu items are shown/hidden based on user status
Customizable	Menu items can be added, edited, deleted, and sorted
Multi-Language	Menu labels can be displayed in multiple languages
Conditional Visibility	Menu items are shown based on user role or status

Default Menu Items:

When the portal is created, the following default menu items are automatically created:

Menu Item	Description	Visibility	URL
Home	Home page link	Open to everyone	/
APIs	API catalog page	Open to everyone	/api-products
How It Works	How It Works page	If feature is active	/how-it-works
Test Tools	Test tools page	If feature is active and logged in	/tools
My Apps	User’s applications	Only logged in	/my-apps
Analytics	Analytics page	If feature is active and logged in	/analytics

Default menu items are automatically created by the system and cannot be deleted. However, their visibility and order can be changed.

Menu Item Visibility Logic:

Menu item visibility is determined based on the following factors:

Always Visible

System Menu Items:

• Home: Always visible (cannot be deleted)
• APIs: Always visible (cannot be deleted)

These menu items provide the portal’s basic functionality and should always be accessible.

Visible If Feature is Active

Conditional Menu Items:

• How It Works: Visible if “How It Works” is active in Portal Settings → Features
• Test Tools: Visible if “Test Tools” is active in Portal Settings → Features
• Analytics: Visible if “Analytics” is active in Portal Settings → Features

These menu items automatically appear in the menu when the related feature is activated.

For Logged In Users

User Menu Items:

• My Apps: Only logged in users can see
• Analytics: Only logged in users can see (if feature is active)
• Test Tools: Only logged in users can see (if feature is active)

These menu items are automatically hidden when user is not logged in.

Navigation Menu Management

1. Go to Navigation Menu Tab

   • Click on “Navigation Menu” or “Navigation Menu” tab in API Portal Settings page
   • Navigation menu management screen opens
2. Managing Menu Items

   You can perform the following operations in the navigation menu:

   Menu Items:

   • Home: Home page link
   • APIs: API catalog page
   • How It Works: How It Works page (visible if feature is active)
   • Test Tools: Test tools page (visible if feature is active)
   • My Apps: User’s applications page (for logged in users)
   • Analytics: Analytics page (if feature is active and user is logged in)

   Menu Item Settings:

   • Visibility: Determine whether menu item will be visible
   • Sorting: Change order of menu items (drag & drop or sequence number)
   • Label: Change the display name of menu item
   • Link: Determine which page the menu item will redirect to
3. Adding Menu Item

   To add a new menu item:

   • Click ”+ Add Menu Item” or ”+ Add Menu Item” button
   • Menu item form opens
   • Label: Enter the name that will appear in the menu
   • Link: Enter the URL to redirect to (internal or external link)
   • Order: Determine its position in the menu
   • Visibility: Select which users it will be visible to (All, Only Logged In, Only Guests)
   • Click “Save” button
4. Editing Menu Item

   To edit an existing menu item:

   • Click “Edit” or edit icon next to the menu item
   • Menu item form opens
   • Make changes
   • Click “Save” button
5. Deleting Menu Item

   To delete a menu item:

   • Click “Delete” or delete icon next to the menu item
   • Say “Yes” in the confirmation dialog
   • Menu item is removed from the menu

   You cannot delete system menu items (Home, APIs). You can only delete custom menu items you added.
6. Changing Menu Order

   To change the order of menu items:

   • Drag and drop menu item to desired position
   • Or change order from sequence number field
   • Changes are previewed immediately
7. Saving

   • After making all changes, click the “Save” button at the top of the page
   • Menu structure is saved and immediately appears in portal top menu

Navigation Menu Features:

Feature	Description
Dynamic Menu	Menu items are shown/hidden based on user status
Multi-Language Support	Menu labels can be displayed in multiple languages
Conditional Visibility	Menu items are shown based on user role or status
Custom Links	Links to internal pages or external websites can be added
Sorting	Menu item order can be customized

Navigation menu directly affects the portal’s user experience. You can provide a better experience by organizing the menu structure according to users’ needs.

Portal Content Management Summary

Portal Pages Management Logic:

Portal content management works according to the following principles:

1. Default Pages:

• Automatically created by the system when each portal is created
• Come with default content
• Content can be customized
• Cannot be deleted or disabled

2. Content-Manageable Pages:

• Managed from Portal Settings → Portal Content Management section
• HTML format content can be added
• Multi-language support available
• Preview feature available

3. Access Control:

• Public Pages: Open to everyone (including users not logged in)
• Private Pages: Only logged in users
• Conditional Pages: Shown/hidden based on feature settings

4. Multi-Language Support:

• If multi-language is active in Portal Settings → General Settings
• Content can be prepared in all enabled languages for each page (Turkish, English, German, French, Spanish, etc.)
• System shows appropriate content based on user’s language preference

5. Page Updates:

• Content changes are immediately reflected on the portal
• Page refresh is sufficient
• Browser cache may need to be cleared

Portal Pages Comparison Table:

Page	Default Content	Access	Customizable	Multi-Language	Preview
Portal Home	Yes	Public	Yes	Yes	Yes
Footer	Minimal	Public	Yes	Yes	Yes
How It Works	Yes	Public (if feature active)	Yes	Yes	Yes
Pending Page	Yes	Private (users in waiting)	Yes	Yes	Yes
Login Page	System	Public	No	Yes	No
Register Page	System	Public (if permission exists)	No	Yes	No
API Catalog	System	Public	No	Yes	No
My Apps	System	Private	No	Yes	No

When managing portal content pages, consider user experience. Content should be clear, understandable, and user-friendly. If multi-language support exists, prepare quality content for each language.

Login Log

The Login Log tab appears in the API Portal Settings header between SEO and Danger Zone. Use this tab to control whether portal user login audit records are written to MongoDB and whether they are forwarded to configured connectors (Elasticsearch, Kafka, Webhook, etc.). These settings are scoped per portal.

Field	Description
Save login logs to database	When enabled, login logs are written to the MongoDB portal_login_logs collection. When disabled, records are only sent to connectors; if connectors are also inactive, records may be lost.
Send login logs to connectors	Forwards login logs to external connection configurations (environment-scoped ConnectionConfig). The table shows Name, Type, and Status; use the + button to add a connector.

For event types, JSON payload examples, and connector setup steps, see Login Log Connector Configuration (Portal section). To view and filter login records in the UI, see API Portal Login Logs.

Danger Zone

Danger Zone is the section where critical and irreversible operations for the portal are performed. This section contains permanent operations such as portal deletion.

All operations in the Danger Zone section are irreversible. Before performing these operations, evaluate all effects and make necessary backups.

Danger Zone - Critical Operations

Portal Deletion

Portal deletion permanently deletes the portal and all its data. This operation cannot be undone.

1. Go to Danger Zone Tab

   • Click on “Danger Zone” or “Danger Zone” tab in API Portal Settings page
   • Critical operations are listed
2. Click Portal Deletion Button

   • Click “Delete Portal” or “Delete Portal” button
   • Confirmation dialog opens
3. Confirm Portal Name

   • You are asked to enter the portal name exactly in the confirmation dialog
   • Make sure you enter the portal name correctly
   • This step is to prevent accidental deletion
4. Confirm Deletion Operation

   • After entering the portal name correctly, click “Yes, Delete” or “Yes, Delete” button
   • Portal is permanently deleted
   • All data (users, APIs, content, statistics) is deleted

Portal Deletion Operation Effects:

Data Type	Status
Portal Configuration	Permanently deleted
User Accounts	All user accounts are deleted
API Products	All API products are deleted
Application Registrations	All application registrations are deleted
API Keys	All API keys are deleted
Content	All content pages are deleted
Statistics	All analytics data is deleted
Files	All uploaded files are deleted

Portal deletion operation cannot be undone. Before deletion:

• Backup important data
• Inform all users
• Evaluate alternative solutions (such as making portal passive)