API Portal Settings

​

General Settings

The portal’s basic configuration settings are made in this section. Fields used for Portal Settings configuration are shown in the table below.

​

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. Fields used for Email Settings are shown in the table below.

​

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

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.

​

Security

Privacy settings to be used on the API Developer Portal side are managed through this screen. Fields used for Security Settings configuration are shown in the table below.

​

Features

Features to be used on the API Developer Portal side are managed through this screen. Fields used for Feature Settings configuration are shown in the table below.

​

Legal

Legal settings to be used on the API Developer Portal side are managed through this screen. The field used for Legal Settings configuration is shown in the table below.

​

SEO

SEO settings to be used on the API Developer Portal side are managed through this screen. The field used for SEO Settings configuration is shown in the table below.

​

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.

​

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 Access Statuses

Portal pages are categorized according to their access status:

​

Portal Pages Working Logic

1. Page Creation and Management: Pages for each portal are created in two ways: 2. Page Content Management: Portal page content is managed in the following ways: 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

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:

​

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: 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

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

​

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

​

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: 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

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

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: 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 Display Scenarios: The Pending Page is automatically displayed in the following situations: 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: Default Menu Items: When the portal is created, the following default menu items are automatically created: Menu Item Visibility Logic: Menu item visibility is determined based on the following factors: Navigation Menu Features:

​

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:

​

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.

​

Portal Deletion

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