Publishing targets
Publish a contract to give consumers a defined set of endpoints and fields. Select the destinations you need, configure their credentials, and review the result for each destination after publishing.
The canonical spec
Enable public artifacts when you want to share the contract's OpenAPI JSON without an Elva login. The hosted URL contains your contract ID:
https://api.getelva.ai/api/public/contracts/{contractId}/openapi.json
This file reflects the contract, not the raw codebase: only selected endpoints, only exposed fields, with your descriptions and constraints baked in.
Everything else you can generate
Target | What you get | Availability |
Theneo | Publish to a selected existing or new documentation project. | Available |
Mintlify | Use the public contract spec with your Mintlify documentation and rebuild. | Available |
SwaggerHub | Publish to your configured API registry destination. | Available |
Postman | Publish a collection to your selected Postman destination. | Available |
MCP server | Generate a hosted MCP server from the contract's selected endpoints. | Available |
Mock server | Serve example responses from the contract for development and testing. | Available |
ReadMe | Documentation publishing integration. | Coming soon |
TypeScript SDK | Generated TypeScript client package. | Coming soon |
Python SDK | Generated Python client package. | Coming soon |
Missing a platform you need? The Publishing step has a “Looking for a different platform?” box — tell Elva where you want the contract to land and submit the request.
The MCP target deserves a closer look
Enable the MCP server target to generate agent tools from the contract's selected endpoints. Review endpoint selection, authentication, and field exposure before publishing, then test the resulting tools with a consumer credential.
The MCP deployment uses the Elva gateway and appears in MCP insights and logs. Install-page visibility is configured separately; public artifact sharing does not replace API authentication.
Publishing can succeed for some destinations and fail for others. Inspect each result and retry failed destinations after fixing their configuration. A failed destination does not roll back destinations that already succeeded.
Where to go next
The enterprise MCP gateway
Where a contract's MCP server runs: auth relay, encrypted credentials, and full call logging.
Sync, drift & the changelog
What happens to published artifacts when the source code underneath them moves.
Configure and verify your destinations
Connect the required integration and select the destination project or collection. For Mintlify, enable and save the public spec before triggering a documentation rebuild. Keep integration credentials in Elva's integration settings, never in a public spec or example.
Review governance checks and approvals, acknowledge breaking-change warnings when required, and publish. Open the generated spec, documentation, MCP tool list, or mock URL to confirm it contains the intended contract. Collection updates and contract sync do not automatically publish these artifacts.
On this page
- Publishing targets