Organization administrators, system administrators, integration engineers, security administrators, and API owners
Control which external systems, applications, or services can access Finger Manager APIs and what they can read or operate.
Control which external systems, applications, or services can access Finger Manager APIs and what they can read or operate.
يمكن تسليم الإشعارات التي يتم إعدادها في Finger Manager داخل Finger Trader App وفق القواعد والجمهور والجدولة.
API permissions control which interfaces external systems, applications, or services can access through the Finger Manager API, which data they can read, and which operations they can execute.
Unlike back-office feature permissions, API permissions mainly apply to system-to-system connections.
For example, an institution can allow one internal system to read customer profiles, retrieve product information, query orders and positions, receive trading signals, send notifications, or update limited business data, while explicitly blocking all unrelated API capabilities.
API permissions help institutions establish independent and controllable access boundaries for different integrations.
API Permissions decide which interfaces an API client can call.
For example, Customer Read allows an API client to read customer information. Without Customer Write, the same client cannot modify customer profiles.
API permissions can independently control Read, Write, Create, Update, Delete, Send, Execute, and Manage capabilities.
Back-office feature permissions apply to Finger Manager users and decide which functions employees can use after signing in to the Manager interface.
API permissions apply to external systems, applications, or services and decide which system capabilities can be accessed programmatically.
The two permission systems can be managed independently. Having Finger Manager back-office permissions does not automatically grant API permissions.
Before using the API, each connected system should receive its own API credential.
Depending on the integration method, credentials can include API Key, API Secret, Client ID, Client Secret, Access Token, Certificate, OAuth Credential, or other authentication information.
CRM System, Trading System, and External Reporting System should use separate credentials so their access scopes can be managed independently.
Read permissions allow API clients to retrieve specified data without changing it.
Examples include Market Data Read, Product Read, Customer Read, Account Read, Order Read, Position Read, Trade History Read, and Notification Read.
Write permissions allow API clients to modify or submit business data.
Examples include Customer Write, Product Write, Account Write, Order Write, and Notification Write.
Because Write permissions can directly affect business data, they should be controlled more strictly than Read permissions.
Some interfaces can separately control create operations, such as Customer Create, Order Create, Notification Create, and User Create.
If a system only has read permission, it cannot create new business records through the API.
Update permission controls whether an external system can modify existing data.
For example, a CRM system can receive Customer Read + Customer Update to sync customer contact fields, but it does not need Customer Delete.
Delete is a high-risk API permission and should not be enabled by default.
Examples include Customer Delete, Product Delete, and Notification Delete.
For orders, trading history, logs, and other critical records, the system can completely avoid providing permanent-delete APIs. Delete capability should be authorized only for specific business needs and risk decisions.
Order-related APIs can be controlled separately, such as Order Read, Order Create, Order Update, Order Cancel, and Order History Read.
Different external systems can receive different capabilities. A market app may only have Order Read or no order permission at all, while an execution system can have Order Create, Order Cancel, and Order Read.
Position permissions can include Position Read, Position History Read, and Position Export.
A system that only displays customer positions can receive Position Read only. If an external system does not need trading data, it should not receive position permissions.
Trading signals in Finger Manager can be read and processed through APIs.
Related permissions can include Trading Signal Read, Trading Signal Receive, Trading Signal Forward, and Trading Signal Manage.
For example, an external risk management system can read real-time trading signals and process them according to institutional risk rules. Finger Bridge forwarding scenarios can also use separate access permissions.
Customer APIs can separately control Customer Read, Customer Create, Customer Update, Customer Status Read, and Customer Status Manage.
For example, an external CRM can read customer profiles, a KYC / KYB system can update review status, and unrelated systems do not need access to complete customer information.
Product APIs can include Product Read, Product Create, Product Update, Product Status Manage, and Market Read.
Finger Trader can use APIs to retrieve product lists, basic product information, trading hours, price precision, and product status, but it usually does not need product back-office management permissions.
External systems can call Finger Manager notification capabilities through APIs.
Examples include Notification Create, Notification Send, Push Send, In-App Notification Send, Email Send, and SMS Send.
For example, when a business system detects a customer account status change, it can trigger In-App Notification + Push Notification through API without requiring operations staff to manually enter Finger Manager.
Institutions can allow external analytics or reporting systems to retrieve data through APIs.
Examples include Report Read, Trading Report Read, Customer Report Read, and Billing Report Read.
These APIs should usually be read-only and should not provide modification capability.
API permissions can also be combined with data permissions.
For example, an API Credential may have Order Read, but its data scope is Japan Entity. In that case, the API can only read orders under Japan Entity even if the endpoint supports other organizations.
A complete API access capability can be understood as API feature permission + data permission.
API Credentials can be bound to a specific Organization.
For example, Japan API can only access Japan Entity, and Hong Kong API can only access Hong Kong Entity. A group-level system can receive multiple organization data scopes if authorized.
This prevents APIs for different business entities from accessing each other's data.
For third-party systems or analytics tools, institutions can create read-only API Credentials.
A read-only credential only allows Read and does not allow Write, Update, Delete, or Execute.
For example, a BI System can have Customer Report Read, Order Read, and Position Read, but cannot modify any Finger Manager data.
When connecting third-party systems, each third party should receive an independent API Credential.
Examples include CRM Vendor, Market Data Vendor, Reporting Vendor, Liquidity Provider, Broker, Custodian, and Compliance System.
Multiple third parties should not share the same credential. Separate credentials allow independent permission control and make it easier to disable one integration later.
For security, API Secret, Token, or other access credentials should be rotated periodically.
A common rotation workflow is: old Credential -> generate new Credential -> update the external system -> confirm the new credential works -> revoke the old credential.
Rotation reduces the risk of using a fixed key for too long.
Important APIs can additionally restrict allowed source IP addresses.
For example, only the fixed IP of a Broker Internal Server can call a specific API. Requests from other IP addresses are rejected.
This is an additional security control beyond API Credential authentication.
In addition to permission names, credentials can be restricted to specific API Endpoints.
For example, a credential can be allowed to call GET /orders and GET /positions, but not POST /orders.
Even inside the same order module, read and execution capabilities can be controlled separately.
APIs can use Rate Limit settings according to system configuration.
Limits can include requests per second, requests per minute, daily request quota, and concurrent connection count.
Different API clients can use different limits to reduce the impact of abnormal requests or faulty programs on system stability.
Some API permissions are highly sensitive and should be strictly controlled.
Examples include Order Create, Order Cancel, Customer Update, Permission Manage, User Manage, Notification Bulk Send, API Credential Manage, System Settings, and Trading Signal Forward.
These permissions should only be granted to clearly required internal systems or reviewed counterparties.
API permissions can be completely independent from Finger Manager back-office user roles.
For example, a back-office user with the Operations role may have notification management permission in the Manager interface, but that does not mean the user has Notification API access.
Conversely, an external system may have API permissions without any Finger Manager login account. This separation avoids mixing human back-office access with system interface access.
Finger Manager can record API calls for audit and troubleshooting.
Logs can include Credential, Client ID, API Endpoint, request time, source IP, request method, response status, and execution result.
For key operations, the log can also record the related business object. For example, at 14:30:22, an API calls Order Cancel for ORDER-100234.
API logs help institutions perform audits and investigate issues.
If abnormal API calls are detected, administrators can disable the credential, revoke the token, change permissions, adjust the rate limit, restrict IP addresses, or rotate the API Secret.
These actions can quickly stop abnormal systems from continuing to access Finger Manager.
API access should also follow the Principle of Least Privilege.
If a market data system only needs Market Data Read, it should not receive Order Write. If a reporting system only needs Report Read, it should not receive Customer Update.
Each API Credential should only have the permissions required for its own business purpose.
The workflow can be understood as: create API Credential -> determine the Organization -> select APIs to expose -> configure Read / Write / Execute permissions -> set the data access scope -> configure IP / Rate Limit security policies -> provide the Credential to the external system -> external system calls API -> Finger Manager verifies the Credential -> checks API permissions -> checks data permissions -> executes or rejects the request -> records the API call log.
API permissions are the programmatic interface access-control capability in the Finger Manager system access-control model.
Institutions can create independent API Credentials for different internal systems, third-party services, or partner institutions, then separately control interface permissions and data access scopes.
By combining API permissions, data permissions, Credential management, access restrictions, and call logs, institutions can keep the system open for integration while precisely controlling access boundaries between different systems.
