An integration is not done when it runs. It is done when you can say who may call it.
Publish workflows as secured APIs, hold the payload contracts in one registry, and scope access per client — without bolting on a separate API gateway to do it.
- API Manager
- Schema registry
- Access profiles
- Promotion
- GET
/v2/employeesLive - POST
/v2/employeesLive - GET
/v2/payroll/runsLive - POST
/v2/payroll/submitIn review - GET
/v2/orders/{id}Mock
The gateway you would otherwise go and buy
Most integration platforms hand you a workflow and leave publishing it to someone else’s product. Koodisi treats the published API as part of the same job — same versioning, same promotion path, same access model.
Secured API collections
Publish a workflow as an HTTP endpoint and group related endpoints into a collection that versions and promotes as one thing.
Client profiles
Each consumer gets its own profile with its own token, so access is granted and revoked per client rather than per platform.
Mock endpoints
Publish the contract before the implementation exists. The team on the other side can build against it while you finish the workflow behind it.
User surfaces
Expose a form or chat surface over a workflow for the people who need to trigger it without an integration of their own.
Access control
Access is token-based and scoped by profile, so you can answer “who can call this endpoint” with a name rather than a shrug. Threat protection is available on higher plans.
One place the payload contract lives
When the contract lives in each workflow, twelve integrations drift into twelve slightly different ideas of what a customer record is. The registry holds the definition centrally, so a change is made once and every integration that touches that payload is measured against it.
Registering definitions is available from the free tier — not read-only access to someone else’s catalogue, but your own contracts, written down.
OpenAPI
The REST contracts your services already publish, held where every integration that calls them can see the same version.
JSON Schema
Payload shapes for the interfaces that never had a formal spec, written once instead of re-derived per workflow.
WSDL
SOAP definitions for the systems of record that are not going anywhere, treated as first-class rather than as a legacy exception.
Who changed it, who approved it, who can call it
The three questions an auditor asks and most integration estates answer badly. Each one is a property of the platform here rather than a process someone maintains beside it.
Approvals on the way to production
A promotion is reviewed before it lands. The approval is part of the deployment record, not a message in a channel somebody has to go and find.
Versioned, with a way back
Every workflow and API collection is versioned, so a bad release is rolled back rather than hot-fixed under pressure.
Scoped per tenant and environment
Multi-tenancy is standard rather than an enterprise upsell, with isolated runtimes, credentials, and audit trails per tenant.
Credentials held in the Key Vault
Secrets are managed with rotation audit instead of living in a workflow's configuration where anyone with edit rights can read them.
Role-based access, encryption, and certifications
Permission scopes, field masking, the encryption toolkit, and where Koodisi stands on SOC 2 and ISO 27001 are all documented on one page, with the evidence a security review asks for.
FAQ
Questions about governing what you build
What gets published, who can reach it, and what shape the data must take.
Still have a question? Talk to an expert.
Bring the API your security review is holding up.
We will walk through publishing it, registering its contract, and scoping who can call it — on your systems, not a demo tenant.
Book a demo