Configure Imou Regional Endpoints: Singapore, Frankfurt and Oregon

Configure the OpenAPI base URL from the data center assigned to the developer account in Control Board → Basic Information → My Information. Current documentation maps East Asia to openapi-sg.easy4ip.com, Central Europe to openapi-fk.easy4ip.com, and Western America to openapi-or.easy4ip.com, using HTTPS POST under /openapi/[method]. Do not choose by end-user location or infer data residency from these labels.

Why it matters

Regional routing is part of credential identity, not a frontend performance setting. A correctly signed request sent to the wrong regional host can fail or address the wrong platform context. Teams often hide this mismatch by rotating secrets, changing signature code, or adding fallback hosts, which makes diagnosis harder and can mix operational records.

The console assignment wins. Geographic proximity, browser locale, customer country, and deployment cloud region are not documented selectors. Endpoint labels also do not establish where all data is stored, replicated, backed up, or processed.

Approach / architecture

Bind each application credential set to one immutable regional configuration:

Config key	Example value	Rule
IMOU_REGION	east_asia	Controlled enum matching console assignment
IMOU_BASE_URL	https://openapi-sg.easy4ip.com:443/openapi	Derived from reviewed mapping
IMOU_APP_ID	Secret-backed reference	Paired with one region
IMOU_APP_SECRET	Secret manager reference	Backend only
SOURCE_REVIEWED_AT	Release metadata	Triggers documentation review

The application should reject unknown or incomplete region configuration at startup. It should never accept a base URL from a browser, customer request, device payload, or general-purpose redirect. If multiple Imou applications are legitimate, partition credentials, region, logs, quotas, and reconciliation jobs by application.

Current documented mapping

The live development specification lists:

Data center label	HTTPS POST pattern
East Asia Data Center	https://openapi-sg.easy4ip.com:443/openapi/[method]
Central Europe Data Center	https://openapi-fk.easy4ip.com:443/openapi/[method]
Western America Data Center	https://openapi-or.easy4ip.com:443/openapi/[method]

Use the method name from the applicable interface documentation. Preserve HTTPS and the /openapi/ path. These are international Open Platform mappings; do not silently mix them with a different portal or China-region configuration.

Six configuration steps

1. Identify the owning developer application. Confirm the appId used by this deployment and which team controls it. Avoid selecting region from a device or end-user profile.

2. Read the console assignment. Sign in to the corresponding account and open Control Board → Basic Information → My Information. Record the displayed data center as controlled deployment evidence.

3. Map assignment to the live documented host. Use the current development specification, not a hostname copied from an old project or search result. Add an explicit enum rather than a free-form URL.

4. Pair region and credentials in secret-backed configuration. Deploy them as one reviewed unit. Prevent one environment from loading an appId from one region and a base URL from another.

5. Run a signed backend test. Use the documented request envelope and signing procedure. Record request id, selected region, method, and sanitized result; never log appSecret, full tokens, or signing source strings containing secrets.

6. Promote with drift checks. Compare the deployed region enum, derived host, and credential reference across environments. Recheck the live mapping before publication and when onboarding another developer application.

APIs / SDKs

The HTTP development specification is canonical for regional hosts, request structure, response structure, and signature calculation. Each HTTPS request contains a system block with protocol version, appId, signature, time, and nonce, plus a unique non-empty request id and method parameters.

Regional configuration and signing should remain separate modules. The signer accepts a credential reference and request metadata; the transport accepts the region-derived base URL. This makes logs and tests show whether a failure arose before signing, during host selection, or in the method response.

Use the official fixed signature test case from the live specification to verify the signing implementation. Do not place its example secret into production. Do not convert documentation time or nonce constraints into unrelated service latency or SLA claims.

Troubleshooting endpoint mismatches

Check in this order:

1. international portal and owning account;
2. console-assigned data center;
3. deployed region enum and derived host;
4. paired appId and secret reference;
5. exact /openapi/[method] path;
6. UTC request time, nonce, request ID, and signature implementation;
7. method parameters and token authority.

Keep the original sanitized result and request ID. Do not automatically retry against all regional hosts. A “first host that succeeds” strategy turns configuration mistakes into cross-region ambiguity and may conceal an incorrect credential inventory.

When support receives a region-related incident, include environment, application reference, console assignment evidence, configured enum, hostname, method, UTC time, and redacted result. Exclude the secret, complete signature input, and reusable token.

Limits & pitfalls

• Do not select a regional endpoint from customer IP, browser locale, DNS latency, or device location.
• Do not implement automatic cross-region failover unless an official, approved architecture explicitly defines it.
• Do not mix international and China portal credentials or hosts.
• Do not infer data residency, replication, disaster recovery, compliance coverage, or SLA from sg, fk, or or.
• Do not expose base-URL choice as an end-user setting.
• Do not keep region independent from its credential set.
• Do not rotate credentials before ruling out a host mismatch.
• Do not log AppSecret, administrator tokens, full signatures, or sensitive params.
• Do not claim that one successful API test proves all device and service capabilities.
• Recheck the console path and documented mapping before publication and every new rollout.

Treat endpoint configuration as reviewed infrastructure code. Changes should state old and new assignment, credential owner, source reviewed, validation method, and rollback. An endpoint edit is not a harmless URL change; it affects every signed API call made with that application identity.

Inspect your application’s assigned data center at Imou Open Platform and validate one signed backend call against the matching documented endpoint before enabling device workflows.