Create the first endpoints

endpoints represent specific web, iOS, or Android access instances in your application. After creation, the system will generate an independent Public API Key for the endpoint.

Open the pop-up window for creating an endpoint

It can be created through any of the following entrances:

Click Create the first endpoints in the application creation success prompt.
Enter Application Management → Application Details → endpoints and click New endpoints.

The console, interface, prompt copy and documents should all use "Endpoint". If the current version still displays "Scene Node", both represent the same object in this guide.

Fill in basic information

Fill in the name and description of the endpoints, and select the platform.

It is recommended that the name include both the business portal and the platform, for example:

Checkout Page Web
Storefront Client iOS
Storefront Client Android

Whether modification is allowed after the platform is created depends on the current console. To avoid confusion about the Public API Key, security configuration, and attribution, treat the platform as a fixed attribute.

Configure Web endpoints

After selecting Web, configure the sources that are allowed access.

Allowed Origins

Origin usually consists of protocol, domain name and port, and does not include the page path.

Valid example:

https://www.example.com
https://checkout.example.com
https://staging.example.com:8443

Do not enter only example.com. Whether wildcards and local development addresses are allowed depends on the console's current verification rules.

Allowed Referers

If the product supports Referer verification, you can further restrict the page paths allowed to call the SDK. The path and wildcard format should be filled in as prompted by the field.

Example:

https://checkout.example.com/*
https://*.example.com/pay/*

When officially accessing, the source range should be as precise as possible to avoid whitelisting uncontrolled domain names.

Illustration: Web endpoints security configuration

Configure iOS endpoints

After selecting iOS, you can enable app signature verification.

After enabling it, fill in the Bundle ID as required by the console, for example:

com. company. app

The Bundle ID should exactly match the actual built and published app. Configuration errors can cause legitimate client requests to be rejected.

If the test version and the official version use different Bundle IDs, the endpoints should be planned separately or corresponding permission rules should be configured.

Illustration: iOS application signature verification

Configure Android endpoints

After selecting Android, you can enable application signature verification.

After enabling, fill in the following as required by the console:

Package Name, for example com. company. app.
App Signature, which is the signature information used by the actual published application.

Package Name and App Signature must be consistent with the actual installation package. If Debug, test and official versions use different signatures, test and production access methods should be designed in advance.

Illustration: Android application signature verification

Set initial rate limits

The endpoint can set request limits per minute and hour to reduce the risk of Public API Key being stolen or abnormal traffic consumption quota.

When configuring for the first time, you can refer to the normal peak value settings of the business and reserve a reasonable margin:

Recommended initial threshold = recent normal peak × 1.5 to 2

The above are only planning methods, not fixed values applicable to all businesses. Marketing, ticketing or payment services with obvious peaks should be set up in conjunction with capacity assessment.

Note when configuring:

The per minute limit multiplied by 60 should not be higher than the hourly limit.
Whether leaving it blank means disabling access-level restrictions is subject to the page description.
Even if access-side traffic limiting is not configured, requests may still be affected by application-level restrictions, organization quotas, and subscription status.
After exceeding the limit, Geelab may reject this request; it will automatically recover after entering the next time window.

Create and obtain Public API Key

After completing the configuration, click Create endpoints. After the creation is successful, the system generates the Public API Key of the endpoints.

Click the copy button in the access list or details to copy the complete Public API Key. After copying:

Provide the key to the R&D personnel responsible for client access.
Only used for the platform corresponding to the current endpoints.
Do not use it to call the Server API.
Do not remove configured source verification, application signature verification, or rate limiting.

Public API Key is a public client key, and it is normal for it to appear in client code; security mainly relies on source verification, application signature verification, rate limiting, and background risk control. It is different from the Region server key which must be kept secret.

Illustration: endpoints details and Public API Key

Create the first endpoints

On this page