A Bookings API change moves through several repositories in the KongAirlines example, from a pull request to production. This page explains the delivery flow that the example implements. It’s a reading guide and not a deployment checklist. kongctl manages Konnect resources. decK manages Gateway configuration. GitHub Actions connects the reviewed artifacts to delivery.
If you want a practice for your own system, see Adapt patterns from KongAirlines.
A service developer changes the root OpenAPI document on a feature branch. The example treats this document as the next development contract. When the contract changes, the example advances its beta version.
The Gateway generator combines the contract with explicit transformation inputs. It generates development configuration from the root contract. It generates production configuration from the retained release that the production Catalog manifest selects. A design change for development only doesn’t change the production candidate.
Observe: the service PR contains the API design and the Gateway configuration that results from it. It doesn’t contain a script that generates unknown output later.
The validation workflow generates both Gateway artifacts without Konnect credentials. It makes sure that the output is correct and uploads the artifacts.
A separate materialization workflow makes sure that the source PR and the artifact boundaries are correct. Then it commits the generated files to the branch in the same repository. Validation runs again. If the output matches, the workflow makes no further commit.
The workflow updates a PR comment that lists the changed input files and the generated Gateway differences. The comment is an offline comparison and not a live Konnect plan. A change to Catalog only can correctly show no generated Gateway differences.
Observe: reviewers can inspect intent and output together. Teams express additional Gateway behavior through transformation inputs and don’t edit generated files. The credentialed workflow doesn’t run scripts that the PR controls. Fork validation doesn’t receive deployment or write credentials.
After the merge, the development synchronization workflow makes sure that the committed Gateway artifacts still match the generated output. It adds the development Catalog version. Then it synchronizes the service’s Catalog state and tagged Gateway configuration with its Konnect identity.
The development manifest references the Dev Portal and the team control plane that the platform owns. The service doesn’t provision duplicate shared resources.
Observe: the service updates its development API and its Gateway configuration directly. It doesn’t deploy a production Gateway change.
When the service is ready to release, its release workflow opens another service PR. The team supplies a stable release version and the next development version. The team doesn’t edit a deployment script.
The release preparation script does four things:
Validation protects retained releases from modification and deletion. When the team merges this PR, the next beta goes to development. The merge also proposes the reviewed production candidate through the promotion workflow.
Observe: reviewers see the selected production specification and the generated Gateway candidate together. A team releases a contract by choice. A development merge doesn’t release a contract automatically.
The promotion workflow copies the committed production candidate into a platform PR. It records the source repository, the commit, the checksum, and the tool versions. It doesn’t regenerate the candidate and it doesn’t deploy it to production.
The platform team reviews the candidate together with the aggregate production configuration. After the merge and the production environment approval, the platform delivery workflow synchronizes the reviewed Gateway state.
Observe: production Gateway changes require platform review. Service teams keep ownership of their APIs and don’t receive production Gateway write permissions. If the Gateway configuration is the same, a promotion can still record a new reviewed source commit in the provenance.
After Gateway synchronization succeeds, platform automation reads the changed provenance. Then it dispatches the production Catalog workflow of the service that owns the change.
That workflow checks out the exact promoted commit. After its own production approval, the service identity synchronizes the production API, the retained specifications, the implementation link, and the Dev Portal publication.
Observe: the platform governs the production traffic path, and the service writes its own production Catalog resources. The two approvals protect different ownership boundaries. These operations don’t form one atomic transaction. Failures appear in the workflow that owns the failed step.
Dev Portal shows the published contract and the application registration process. Flights and Destinations show public operations. Bookings and Customer show access with an application key after registration approval.
Documentation visibility, application registration, and runtime access are three different controls. Before you adapt the protected API example, read the authentication decisions.
The workflows in this page deploy Konnect and Gateway configuration. They don’t deploy the upstream application services. To test end-to-end behavior, send requests through a running Gateway to compatible upstream services.
You can adopt reviewable generation, release PRs, or governed promotion independently. The pattern guide links each practice to its implementation and to the boundaries that you must keep.