Definition
API Gateway (API gateway) is a unified entry point for external calls, responsible for request authentication, rate limiting, routing, protocol conversion, and logging. In ICMP, the API Gateway handles calls from customer systems to RESTful API, and works with Webhook callbacks and OAuth2 authentication to ensure the security, controllability, and observability of the interfaces.
Core Functions
The core capabilities of the API Gateway include: Authentication and Authorization — verifying API Key, JWT, OAuth2 Token to check the caller's identity and permissions; Rate Limiting and Circuit Breaking — limiting requests by QPS, concurrency, and quota to prevent abuse and overload; Routing and Versioning — routing requests to the corresponding microservices, supporting version switching and gradual release; Protocol Transformation — providing a unified REST entry point, while internally connecting with gRPC, message queues, etc.; Logging and Monitoring — recording request logs, latency, and error rates, supporting Audit Trail and operational analysis.
Practice in ICMP
SimtoLink ICMP's API Gateway exposes RESTful APIs externally, supporting capabilities such as SIM management, usage query, activation/suspension, and billing retrieval. Customers obtain access tokens through API Key or OAuth2, which the Gateway verifies before forwarding to the BSS/OSS backend. The platform supports rate limiting policies configured per customer and per interface, ensuring multi-tenant isolation and system stability. Combined with Swagger documentation and SDK, it lowers the integration threshold for customers.
Security and compliance
API Gateway is the first line of defense for security protection. In addition to authentication, it needs to support HTTPS, TLS encryption, replay prevention, injection prevention, etc. In cross-border scenarios, it must comply with Data Residency and GDPR requirements, and sensitive operations must be recorded in the Audit Trail. The platform can configure IP whitelists and regional restrictions to further tighten access policies.
Which request fields the gateway rewrites before it forwards
The API gateway sits between the customer system and the connectivity platform’s backends. Callers see one set of stable addresses. Inside, there can be several services. Before forwarding, the gateway checks who the caller is, which quota this call counts against, and which backend version should receive the request. It rewrites the path, headers, and protocol when needed. The customer presents an API key or a token. The gateway checks the signature, expiry, and scope before it lets the call through. The caller identity the backend receives should be the tenant and operator the gateway has confirmed, not a username the client typed in itself.
The gateway also observes. Each request leaves a time, path, result code, and duration, and sensitive actions go on into the audit log. It does not decide whether a particular SIM should be activated. That is a backend business rule. It rejects requests that have no identity, exceed a quota, or hit the wrong version. Putting business decisions in the gateway makes the same rule differ between the console and the API. Protocol conversion should change only the carrying format, for example a uniform resource style outside and another call style inside. It must not quietly change the SIM identifier or the customer identifier.
When a token, a quota, and a route can all apply at once
All three controls must hold before a call reaches the business service. The token must be unexpired, addressed to the right audience, and scoped to the current action. The quota is counted per customer, per API, or per time window, and exceeding it returns a rate limit, not an authentication failure. The route sends the request to the matching backend by path and version. During a gradual rollout, the same customer should stay on the same version. If any condition fails, the call should not be counted as a successful business action. A large clock skew can make a freshly issued token look expired. That is not the same error as insufficient permission.
Writes also need an idempotency condition. If a client retries activation, suspension, or an invoice query because of a timeout, the gateway should recognize the duplicate from the idempotency key and avoid executing it twice in the backend. A cache used only for queries must include the tenant in the cache key. One customer’s SIM list must not be returned to another. If a cross-border call terminates transport-layer security along the path, certificate checks should still finish at the gateway. A clear-text API must not be exposed beyond the termination point and still offered outward. Logs for high-risk writes need to link to the audit trail. An access log on the gateway alone cannot reconstruct which SIM was changed.
What to check first when authentication succeeds and the call is still refused
If the token is valid and the call is still refused, look first at rate limiting, insufficient scope, or a route to a version that has been retired. Showing all three as the same failure makes the customer rotate keys while the problem is the quota or the path. When a source-address allow list sits in front of the gateway, a change in the customer’s egress address shows up as intermittent failure, and the token itself is fine. Another error is letting a retry storm in. When the backend slows, the client immediately retries in parallel, the gateway quota fills with retries, and genuine new requests are refused too.
Caches and conversion also create false success. Caching an authenticated query by path, and ignoring the tenant inside the token, lets a later caller read the previous customer’s data. If protocol conversion drops the idempotency key or the correlation ID, the backend cannot deduplicate. A suspend API called twice may run once or twice, and the result is unpredictable. On the day a version changes, if the documentation, the gateway route, and the backend fields disagree, an old client treats the new fields as an error. The check order should stay identity, quota, route, then backend result code, rather than editing business data first. Production rate limits should be set per customer. Do not take the loose quotas from a test environment straight into production.
When a new version is released, the gateway route, the backend fields, and the notes given to customers should take effect on the same day. Changing only the route, and not the notes, makes old calls treat a new required field as a fault. Changing only the notes, and not the route, makes customers send the new document’s payload into the old service, which drops the new fields. During a gradual rollout, pin the version by tenant rather than by a random share. Otherwise consecutive requests from the same customer sometimes succeed and sometimes lack fields. On rollback, look at the rate-limit counters as well. Failed retries from the new version can exhaust the quota, and then normal calls to the old version are refused too.