API management for SaaS products

API management for SaaS products: why a public API is a contract with customers

A public API is a commercial promise. Customers build integrations on it, they pay for plans that set their call volumes, and they plan their own uptime around yours. A self-hosted gateway such as Apache APISIX or Kong Gateway can run API keys, plan assignments and tier-based rate limits inside your own cloud accounts or data centers, so the enforcement point for the commercial model sits under your control rather than in a third-party platform. The platform choice is the easier part. The harder questions are how plans map to gateway consumers and limits, who can change them, and how a limit change is tested before customers see it.

What separates a SaaS provider from other industries is that the commercial model reaches the customer directly, and several regulations reach the provider directly too. Under NIS2, cloud computing and data center providers are treated as digital infrastructure, and Commission Implementing Regulation (EU) 2024/2690 sets technical requirements for cloud and managed service providers, so confirm early whether your service falls in scope. GDPR Article 28(3) requires processor contracts to limit processing to documented instructions, which affects what your gateway logs and where it keeps them. The EU Data Act requires data processing services to let customers switch providers or move to on-premises infrastructure, and from 12 January 2027 switching charges are prohibited. Your API keys, plan data and usage records are part of that switching story.

The short platform answer is this: run the gateway in your own infrastructure, keep plan and key configuration in version control, and treat every tier change as a release. Ask your implementation partner how keys are issued and revoked, how usage is metered per plan, how logs are scoped for GDPR purposes, and how a customer's configuration would be exported if they switch. Confirm the current APISIX release and support status against the APISIX downloads page before you commit to a version.

Which requirements shape a SaaS API gateway build

This table maps the requirements that most affect a public SaaS API gateway to what each one means for the build. Read each row as a design input: the requirement on the left determines where a control sits, what the gateway must log and which contract or configuration decision follows. Confirm the applicability of each regulation with counsel before design work starts.

Requirement	Source	What it means for the build
Per-tier rate limits and quotas	Product plan design and gateway traffic controls	Define limits per consumer key and per plan, enforce them at the gateway, and store counters in a shared store if several gateway nodes serve the same tier.
Customer key lifecycle	Internal security policy and identity provider design	Plan issuance, rotation, revocation and scoping of API keys, and decide whether keys, OAuth clients or both are used for each customer type.
Versioned routes	API product governance	Version routes by path or header, keep old versions routable for a published deprecation window, and manage route configuration in Git so changes are reviewable.
Tenant data isolation	Application architecture and access controls	The gateway can enforce which tenant identity reaches a backend, but object-level authorization stays in the application. Test cross-tenant access in the service itself.
GDPR Article 28(3) processor instructions	Regulation (EU) 2016/679, Article 28(3)	If DeployOpen or a partner operates the gateway for you, the contract must bind the processor to documented instructions, including on transfers, and to Article 32 security measures.
NIS2 cloud provider obligations under Annex I and Implementing Regulation (EU) 2024/2690	Directive (EU) 2022/2555 Annex I and Commission Implementing Regulation (EU) 2024/2690	If your service falls in a NIS2 sector, confirm whether the implementing regulation's technical requirements apply to your gateway hosting or your own service. Gather evidence on access control, logging and incident handling.
Data Act switching rights under Articles 23, 25 and 50	Regulation (EU) 2023/2854, Articles 23, 25 and 50	Customers may need to move to another provider or to on-premises infrastructure. Keep gateway configuration exportable, document routes and plugins, and confirm the notice and transitional periods with counsel.
Cyber Resilience Act Article 14 reporting date	Regulation (EU) 2024/2847, Articles 14, 69 and 71	Reporting obligations have applied since 11 September 2026 to in-scope products. If you ship software with digital elements, confirm whether your gateway components fall in scope and prepare vulnerability reporting processes.

What customer traffic and API data the gateway touches

The gateway sees more customer data than most teams expect, so the first decision is to list it. Every request carries an API key or OAuth access token in a header, a customer or tenant identifier that the gateway maps to a plan, the request payload itself, and the response metadata that drives usage counts. The payload is the sensitive part: a gateway that terminates TLS and logs bodies holds the customer's records in transit and possibly at rest. Decide per route whether bodies are logged, truncated or dropped, and confirm that your access log format does not write Authorization headers or query-string tokens to disk.

Plan lookup, usage metering and key storage normally sit beside the gateway rather than inside it. The gateway needs to know which plan a key belongs to and whether the monthly quota is spent, so it calls or caches a key store and a metering service. Each of those stores holds personal data or identifiers linked to a customer, and the SaaS company is the controller while your own infrastructure or hosting partner acts as processor. Under GDPR Article 28(3), the processor contract must limit processing to documented instructions, including transfers, and require the security measures of Article 32. Confirm that the metering and key stores are covered by the same contract as the gateway, and that their logs, backups and replicas are in the scope of that contract.

Gateway configuration is state too, and in Apache APISIX it lives in different places depending on the deployment mode. In traditional and decoupled modes, routes, consumers, plugins and upstreams are stored in etcd, which the Admin API on port 9180 writes to. In standalone mode there is no etcd, and the configuration comes from conf/apisix.yaml or conf/apisix.json or from the API. Consumer records in etcd or YAML include key material and plan assignments, so treat that state as customer data. Decide who can write it, where it is backed up, and whether it is version controlled in Git. The choice of mode determines the answer, and the cluster sizing and etcd operations work that follows from it should be scoped during architecture review.

Choosing APISIX deployment modes for multi-region SaaS

Traditional mode runs the data plane and control plane together on each node, so every gateway instance reads its configuration from the same etcd cluster it is part of. Client traffic arrives on port 9080 and the Admin API listens on port 9180. This is the simplest topology to reason about for a single region, and it keeps routes, consumers and plugin settings in one place.

Regional fit: Each region tends to run its own cluster, so a regional outage stays regional, but cross-region replication of etcd must be designed deliberately.
Control plane location: The Admin API sits next to the traffic path, so an etcd or Admin API failure in one region can affect configuration changes for that region only if clusters are kept separate.
Exposure: Port 9180 must never be reachable from public networks, which matters more when the same nodes also serve customer traffic.
Scaling: Adding regional nodes also adds etcd members, which affects write latency and quorum planning.
Upgrades: Gateway upgrades touch the control plane as well, so change windows need to be planned around both roles.

Confirm with the vendor how etcd behaves across regions for your chosen version, and test a simulated loss of one region's etcd quorum in your own environment before you rely on this mode for failover.

Standalone mode removes etcd entirely. Each gateway loads its configuration from conf/apisix.yaml or conf/apisix.json, or receives it through the API. Per the deployment modes documentation, APISIX checks the file for changes every second and hot-reloads without restarting. Because each node holds its own copy, regional failover does not depend on a shared datastore.

Regional fit: Each region can run an independent gateway with the same configuration file distributed by your existing delivery pipeline, which suits strict regional isolation.
Control plane location: There is no central control plane in the traditional sense. The source of truth is your Git repository and delivery pipeline, so their availability and access controls become the change control path.
Consistency risk: Nodes can drift if a file update reaches some regions and not others, so you need checksums, health checks or a configuration audit.
Dynamic changes: Confirm which features, such as consumer or key management through the API, are fully available in standalone mode for your version before designing customer onboarding around them.
Plugin coverage: Verify that every plugin your customer plans depend on behaves identically in file-driven mode.

Confirm the reload behavior and any limits on API-driven changes with the vendor, then rehearse a configuration rollout and rollback across two regions in your own test environment.

Which open-source gateways fit a SaaS public API

A public API for customers needs a gateway that can enforce keys, plans and tiered limits while staying inside your infrastructure. The options below differ mainly in plugin coverage, licensing terms and whether you need a separate AI gateway for resold model access.

Apache APISIX as the core gateway

APISIX is licensed under Apache-2.0, and version 3.19.0 was released on September 28, 2026. Its documentation describes more than 100 built-in plugins covering authentication, traffic control and observability, which is where most key management and tier-based rate limiting is configured. Check which plugins your plans need, and whether any of them come only from a commercial edition. Confirm this against the current plugin list before you commit to a design.

Developer sign-in with openid-connect

The APISIX openid-connect plugin works with identity providers such as Keycloak, Auth0, Microsoft Entra ID, Google and Okta, and supports authorization code, client credentials, token introspection and PKCE flows. For a public API, this separates developer portal sign-in from machine client credentials. Decide which flow each customer type uses, and confirm how your chosen identity provider issues and revokes client secrets.

Kong Gateway as an alternative

Kong Gateway is licensed under Apache-2.0, and version 3.9.4 was released on October 12, 2026. It is a practical option when your team already runs Kong for internal traffic and wants one control model across estates. Compare its consumer, key and rate-limit features against your plan matrix, and confirm which capabilities are in the open-source edition and which require a paid Kong offering.

LiteLLM or APISIX for resold model access

If your SaaS product resells access to language models, a gateway that sits between your application and model providers handles per-customer keys, budgets and usage logging. LiteLLM is MIT licensed except its enterprise directory, and APISIX also positions itself as an AI gateway. Keep this separate from your customer-facing API plan logic, and confirm which per-tenant budget and logging features your plans require in the open-source edition.

Dify and multi-tenant licensing

Dify is licensed under a modified Apache License 2.0 that requires a commercial license to operate a multi-tenant service from the source code. If your product offers customers a hosted, multi-tenant Dify-based feature, this condition applies directly. Have counsel review the license terms against your deployment model before you choose Dify as a component of the public API or its AI features.

Developer onboarding without a commercial portal

This sequence takes an external developer from first sign-in to a working, metered API key, and keeps that key's lifecycle under the company's control from issue through retirement. Each step produces a record or check that the platform team can audit, using the identity provider and gateway the company already runs.

Register the developer in the company identity provider
The developer creates an account through the identity provider that the company already operates, such as Keycloak, Microsoft Entra ID or Okta, or through a federated customer identity service. The company's own sign-up page or a minimal developer page, built by the internal team or scaffolded by a partner, redirects to that provider rather than storing passwords in a separate store. The step is done when the account exists, is verified, and carries an organization or tenant attribute that the gateway can read. Confirm with your identity team whether self-registration and email verification are enabled for external users.
Issue a scoped key bound to a plan
After sign-in, the developer requests a key from a small page or API that the company builds, and the request is checked against the subscription record for the developer's organization. The key is tied to a plan, such as a tier that sets request quotas and permitted endpoints, and the scopes it carries reflect only the APIs in that plan. The company's own service (or a partner-built one) writes the consumer record to the gateway's configuration store, and the key is shown once. The step is complete when a test call with the new key succeeds on an allowed route and fails on a route outside its scope.
Publish OpenAPI definitions and a sandbox route
The API team publishes versioned OpenAPI definitions from the same source repository that generates the gateway routes, so the documentation and the enforced routes cannot drift apart. A sandbox route, separate from production and backed by test data, lets developers try calls before they go live. The gateway configuration for both lives in Git, and changes go through review. The step is done when the published specification validates, the sandbox returns expected responses for the documented examples, and the production route is unchanged by sandbox traffic.
Enforce per-key limits at the gateway
The gateway applies the rate and quota limits defined for each plan to every key, so a tier's limits are enforced on the data plane rather than in application code. Apache APISIX and Kong Gateway both provide traffic-control functions for this, and the exact configuration should be confirmed against the version the company deploys. Limit responses should return clear status codes and headers so developers can handle throttling in their own clients. The step is done when load tests show each key is throttled at its plan limit and that one key's traffic does not affect another's quota.
Rotate and revoke keys on request
Developers can create a second key before retiring the first, which lets them rotate without downtime. The company's key service marks a key as revoked in the gateway's consumer configuration, and the change should take effect on the data plane without a restart. Revocation also applies when a subscription lapses, when a credential is reported leaked, or when the account is disabled in the identity provider. The step is done when a revoked key is refused on its next call and the revocation event is written to the access log with the key identifier, not the secret.
Retire old versions with notice
When an API version is scheduled for removal, the company notifies every key holder through the registered contact on each developer account and marks the version as deprecated in the published OpenAPI document. Traffic on the old route is measured per key from the gateway's observability data, so the team can see which customers still depend on it before the route is disabled. The notice period and the removal date are set by the company's own policy and communicated in writing; confirm whether any customer contracts or regulatory obligations set a minimum period. The step is done when the old route returns a clear response, the documentation reflects the change, and the retirement is recorded in the change log.

Rolling out tier limits and versions without breaking customers

Changing a rate limit, retiring an API version or upgrading the gateway can break customer integrations that never changed a line of code. The safe approach is to keep the old behavior reachable while new behavior is proven on a small slice of traffic. In APISIX terms, that means running the current and the next route definitions side by side, moving consumers across in stages, and only then removing the old route. Version paths such as /v1/ and /v2/ give each integration a stable address, so a customer can stay on /v1/ until they have tested /v2/ against their own staging keys.

Canary routing is the second tool. APISIX route definitions can split traffic between upstreams by weight or by matching rules such as a header or a consumer group, so a new tier limit or a rewritten plugin chain can first serve internal test keys and a few friendly customers. Watch the metrics that matter for each tier, including 429 responses per consumer, latency and upstream errors, before widening the rollout. Rate limits deserve the same care. Lower a tier's quota in steps and confirm with the customer success team which keys are affected, because a quota reduced in one step can be the first a paying customer notices.

Plugin and gateway changes need a different discipline because of how APISIX applies them. Its file-driven standalone mode checks conf/apisix.yaml for changes every second and hot-reloads without a restart, and the admin API applies changes to running nodes in the same way. A bad plugin configuration therefore reaches live traffic almost immediately. Treat every region as its own rollout: apply the change to one region, run the canary checks, then move to the next. Confirm with the vendor and in your own test environment how your chosen deployment mode propagates changes across data plane nodes in each region, and keep the previous configuration in Git so a rollback is a tested step, not a manual edit.

Rollout phases and what each phase delivers

The sequence moves from an inventory of today's APIs and plans to a tested gateway in a non-production region, a controlled developer pilot, a multi-region cutover with a rollback path, and a handover that leaves your team able to run and upgrade the platform. Each phase closes with a written output that the next phase depends on.

Discover current APIs, plans and traffic
DeployOpen works with your product, platform and security teams to list every public and partner API, its owner, its authentication method and its current traffic pattern. The team also documents existing plans, tiers and any rate limits enforced today, including those buried in application code. The phase is complete when you hold an agreed API inventory and a list of plan and limit rules that the new gateway must reproduce, with open questions assigned to named owners.
Decide architecture and deployment mode
Using the inventory, the team selects between Apache APISIX and Kong Gateway, chooses a deployment mode for each region and confirms where the control plane will run. For APISIX this means choosing among traditional, decoupled and standalone modes, weighing how each handles configuration distribution across regions. The output is a written architecture decision record covering identity provider integration, configuration storage in Git, and network placement. It is done when your architecture and security reviewers have signed the record.
Build keys, plans and limits in a non-production region
The engineering team builds consumer keys, subscription plans and tier-based rate limits in a non-production environment, along with the authentication flows for customers and internal services. Configuration is written as code and reviewed like any other change. Test cases cover each plan boundary, quota exhaustion, key rotation and revocation. The phase is complete when every plan passes the agreed test suite and your team can reproduce the environment from the repository.
Run a developer onboarding pilot
A small group of customers, chosen with your account and product teams, receives access through the new gateway. DeployOpen supports them through key issuance, documentation of the public endpoints and error responses, and the first integration work. The team records onboarding time, support tickets, limit rejections that customers did not expect and any plan rules that behaved differently from the existing setup. The phase closes with a pilot report listing the fixes made and the changes still required before general access.
Cut over to multiple regions with a rollback path
The gateway is deployed to each production region and traffic is shifted in stages, with the previous routing kept available for a defined rollback. Health checks, error rates and latency are compared between old and new paths at each stage. Rollback steps are rehearsed before the cutover, not written during it. The phase is complete when all regions serve production traffic through the new gateway, and the rollback has been tested in a non-production copy of the same configuration.
Hand over operations and the upgrade runbook
DeployOpen documents the running system, including configuration layout, monitoring dashboards, alert ownership, backup and restore steps, and the procedure for upgrading gateway versions across regions. Your operations staff perform at least one supervised upgrade or configuration change before the handover is accepted. The output is an operations runbook and a named support model. Ongoing support and upgrades can be arranged as a separate retainer, and the terms are set in the written scope.

Evidence a SaaS provider's auditors and customers will ask for

This table maps the evidence that auditors and enterprise customers typically request for a public API to the standard or regulation that asks for it and the gateway or platform component that produces it. Read each row as a question to answer before the assessment starts, not as a certification claim. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue any report.

Evidence	Standard or regulation	Producing component
Logical access and authentication records for the API, covering who called what and with which credential	SOC 2 security common criteria CC1 to CC9, mapped to access controls	Gateway access logs, identity provider audit trail, key lifecycle records
Quarterly or periodic review of API consumer keys, plans and administrator accounts	SOC 2 security common criteria, access review expectations	Admin API change history, identity provider group reports, exported consumer list
Gateway control set described as designed at a point in time, with the configuration as deployed	SOC 2 Type 1 scope: system description and control design as of a date	Versioned gateway configuration in Git, deployment records, plugin inventory
Proof that gateway controls operated consistently across an observation period	SOC 2 Type 2 scope: operating effectiveness over a period	Continuous log retention, alert history, change tickets tied to route and plugin updates
Network and access controls for the gateway tier, including TLS settings, segmentation and admin access restriction	ISO/IEC 27001:2022 technological controls (Annex A, section 8)	TLS policy configuration, network policies, admin API allowlists, bastion session logs
Documented security measures for the gateway and the services behind it, with evidence they are tested and kept current	NIS2 Article 21(2) measures, detailed by Implementing Regulation (EU) 2024/2690	Vulnerability scan results, gateway upgrade records, incident and patch logs
Automatic event records for AI endpoints exposed through the gateway, kept for the required period	AI Act Articles 12(1) and 19(1), if the API serves high-risk AI systems	Gateway access logs and AI gateway logging, forwarded to retained storage
Per-customer usage records for metering, plan enforcement and billing disputes	Customer contract terms and data processing agreements (GDPR Article 28)	Rate limit counters, consumer-tagged access logs, usage export jobs

How much does it cost to run a SaaS public API on self-hosted APISIX or Kong?

What does it cost to run a SaaS public API on self-hosted APISIX or Kong?

The software is free to download under Apache-2.0 for both Apache APISIX and Kong Gateway, so the cost sits in infrastructure, build work, operations and testing. Your spend falls into four groups: cloud or data center capacity for the gateway and its state store, one-time integration work (plans, keys, identity, developer onboarding), recurring operations and upgrades, and security testing. The largest variables are the number of plans and tiers, the number of identity flows you must support, the traffic profile and how many regions you run. Ask any partner for a quote built from a written scope that lists each of these items separately, so you can see which costs are one-time and which recur.

How long does it take to build a public API gateway for SaaS customers?

Duration depends on how much of the customer-facing model is already defined. Teams that have settled their plans, key format, rate limits and versioning policy move faster than teams deciding those things during the build. The work usually includes standing up the gateway in your chosen deployment mode, wiring authentication, configuring tier-based rate limits, adding observability and building developer onboarding. No timeline is given here because it has to follow a written scope. Ask for the milestones, the dependencies on your identity provider team and the acceptance tests for each milestone before you agree on dates.

What does our team need to supply before a gateway build can start?

Most delays come from missing inputs, not from the gateway itself. Prepare these before scoping:

A written plan catalog: tiers, quotas, burst rules and what each tier may call.
Your identity provider details, such as Keycloak, Microsoft Entra ID or Okta, with the OAuth or OIDC clients you intend to issue.
Traffic data: current or forecast request volumes, peak patterns, payload sizes and the top endpoints.
An API inventory with owners, versions and upstream services.
The regions and hosting accounts where the gateway may run, and your Git and CI/CD standards.

The APISIX openid-connect plugin supports authorization code, client credentials, token introspection and PKCE flows, which lets your identity team choose the flows that match your customers. Confirm the flows you need before scoping.

Can an in-house platform team run a self-hosted SaaS API gateway?

Often yes, if the team already runs production Linux, container or Kubernetes platforms, manages secrets and operates identity services. The gateway itself is documented and open source, and APISIX supports traditional, decoupled and standalone deployment modes, so you can match the design to your skills. The harder parts are ongoing: on-call coverage for the gateway, plugin and policy changes made by product teams, version upgrades and developer-facing support. Compare the hours your team can commit with the operating model you need. A partner can build and hand over the platform, run it under a retainer, or split the work. Ask each option for a written responsibility split.

What recurs after launch for a self-hosted API gateway?

Recurring cost falls into three areas. Infrastructure runs continuously across production and any non-production environments, and grows with traffic and regions. Upgrades recur because gateway releases such as APISIX 3.19.0, published on September 28, 2026, need testing against your plugins and routes before rollout. Testing also recurs: application and API security testing after material changes, and reviews of rate limit and authentication configuration as plans change. Add ongoing support if you want named coverage for incidents. Ask for the upgrade cadence, the test scope per release and the rollback procedure in the quote.

Do the EU Data Act switching rules change the gateway architecture?

Yes, they influence design, though they do not require a particular gateway. The Data Act requires data processing service providers to let customers switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transitional period. From 12 January 2027, providers may not impose switching charges. If you are a provider of such services, keep configuration in version-controlled files, document routes, plans and keys in portable formats, and avoid proprietary dependencies in plugins. Self-hosting in your own accounts helps but does not settle the question alone, so confirm the obligations that apply to your service with counsel.

How does multi-region deployment add cost to a SaaS API gateway?

Each region adds gateway capacity, state store capacity and network paths, so cost rises with the number of regions and their redundancy. Under APISIX's decoupled mode, a control plane and data planes share one etcd cluster, so you must decide where the control plane lives and how data planes in other regions reach it. Standalone mode removes etcd but moves configuration delivery into your own pipeline. Plan for cross-region traffic, certificate management per region, monitoring in each region and extra test cycles for failover. Ask for the regional topology, the failover test plan and the cost of running a second region before you commit to multi-region.

Which cost items should we compare across build, partner and managed options?

Compare the same scope across all three options. For a self-hosted gateway, you pay for infrastructure, build labor, operations and testing, and you keep control of data and configuration. For a partner-run gateway, you still pay infrastructure and add a service fee tied to the scope, support level and upgrades. For a managed API platform, you usually pay a subscription or per-call charge, so expenses rise with call volume. Ask each vendor or partner for a multi-year view that shows one-time and recurring items side by side, the per-call cost at your projected peak and the exit costs if you change provider.

Questions to ask an implementation partner before signing

Start with where the control plane lives and how many of them you will run. A SaaS API platform usually needs a data plane close to customers in each region, but the control plane, the component that holds routes, consumers and plugin settings, may be shared or per region. Ask the partner to draw each option for your regions, state which deployment mode they recommend, and explain the trade-offs. APISIX offers traditional, decoupled and standalone modes, and the choice changes how etcd is clustered, how the Admin API is exposed (traditional mode listens on port 9180) and how a regional outage propagates. Ask who holds the etcd or configuration source of truth in each region and how a failed region is isolated.

Ask where API keys, plan assignments, rate limit counters and consumer records are stored, who can read them and how they are encrypted at rest and in transit. Keys should be stored as hashes wherever the platform allows it, and you should confirm that plan and tier data cannot be altered by a developer account. For identity, ask the partner to name the identity provider they will connect through the openid-connect plugin, which flows they will enable (authorization code with PKCE for developer portals, client credentials for machine clients, token introspection for resource servers) and how token audiences map to your plans. Request a written list of every Admin API role and who holds it. On configuration, ask how routes, plugins and consumers are kept in Git, who reviews changes, and whether a pipeline validates them before they reach a region. Ask how they test the OWASP API Security Top 10 risks, which tools and scopes they use, whether testing is repeated after each gateway upgrade, and how object-level authorization flaws are handled, since that check stays in your services. Finally, ask how gateway upgrades are rolled out across regions, and who signs the GDPR Article 28 processor terms with you, including the sub-processor list and instructions on transfers.

Ask for the evidence package before you need it. For SOC 2, the AICPA 2017 Trust Services Criteria apply to every examination through the security common criteria, so ask which controls the partner will document for change management, access reviews, logging and incident response, and whether they will prepare evidence for a Type 1 point in time, a Type 2 observation period, or both. For ISO/IEC 27001:2022, ask which Annex A controls they map to your environment and what statement of applicability input they will supply. Be clear that the partner prepares systems and evidence, while independent auditors and certification bodies issue reports or certificates. If your SaaS serves EU customers, check whether the platform falls in NIS2 or Cyber Resilience Act scope, and ask the partner to confirm which obligations apply to your product, not theirs. Ask for a written scope, named deliverables and a timeline before work starts, along with the retention period for logs, which matters if AI features are also exposed through the gateway. Confirm these details with the partner and your counsel rather than accepting general assurances.

How DeployOpen scopes and runs a SaaS API gateway

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so a public API for SaaS customers can run on a gateway the client controls. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory the public endpoints, customer tiers and expected traffic per plan before choosing a gateway deployment mode.
Define key issuance, plan limits, developer onboarding steps and versioning rules in the written scope.
Agree which regions, clusters and identity provider connections are in scope, and which are left to the client.

How we build

Deploy the chosen gateway, such as Apache APISIX or Kong Gateway, in the client's cloud accounts or data centers.
Configure key authentication, per-tier rate limits and request logging, and keep route and plugin configuration in version control.
Test the gateway against the OWASP API risks and document which controls stay in the application, such as object-level authorization.

How we hand over

Deliver architecture diagrams, runbooks for key rotation and plan changes, and a route and plugin inventory.
Train the client's platform and security teams to operate the gateway, roll out upgrades and respond to alerts.
Provide documentation that supports the client's own evidence for SOC 2 or ISO/IEC 27001 assessments, which independent auditors conduct.

How we support

Offer ongoing support, gateway upgrades and continuous testing as a retainer after handover.
Review new public endpoints and plan changes against the agreed scope and update configuration through change control.
Run periodic security testing of the public API and report findings with remediation steps the client can verify.

API management for SaaS products