> ## Documentation Index > Fetch the complete documentation index at: https://docs.mirurobotics.com/llms.txt > Use this file to discover all available pages before exploring further. # Create > Create a new config type. | Scope | Required | | -------------------- | -------- | | `config_types:write` | Yes | ## OpenAPI ````yaml /references/platform-api/2026-05-06.yaml post /config_types openapi: 3.0.3 info: title: Miru Platform API description: The API between Miru and any external client version: 2026-05-06.rainier license: name: MIT url: https://opensource.org/licenses/MIT x-release-version: 2026-05-06.rainier-beta.3 x-git-commit: sha: 79734a65778aea4131f502774643d1d69a262542 url: >- https://github.com/mirurobotics/openapi/commit/79734a65778aea4131f502774643d1d69a262542 message: >- fix(release/stainless): publish stainless.yml asset for platform and device (#57) ## Summary The release workflow publishes a `stainless.yml` asset alongside each spec release for downstream Stainless SDK pipelines. It worked for `cli` and `frontend` audiences but silently skipped `platform` and `device`. **Root cause:** `STAINLESS_CONFIG` in `tools/release/stainless.py` pointed `device` and `platform` at a nested layout (`tools/stainless/{device,platform}/stainless.yml`) that never existed. The actual files have lived at the flat `tools/stainless/{device,platform}.yml` since commit `214bf44` (2026-03-04, "refactor(stainless): simplify config names to platform.yml and device.yml"). The mismatch was masked by `build_stainless_target` silently returning `None` when the source file was missing, so every platform and device release shipped without its `stainless.yml` asset. ## Changes 1. **Fix the two paths in `STAINLESS_CONFIG`** to point at the flat `tools/stainless/{platform,device}.yml` layout that exists on disk. 2. **Replace the silent `if not src.exists(): return None`** with `raise FileNotFoundError(...)` so a future mapped-but-missing config fails loudly. Audiences not in the dict (agent, mqtt, webhooks) still return `None` cleanly — that's the legitimate "no Stainless SDK for this audience" case. 3. **Add regression tests:** - `test_known_audiences_have_real_files_on_disk` — parametrized over `STAINLESS_CONFIG.items()`, asserts each path resolves to an existing file. This is the test that would have caught the original bug. - `test_missing_src_for_mapped_audience_raises` — replaces the old `test_missing_src_returns_none`, pins the new loud-error contract. - `test_unmapped_audience_returns_none_cleanly` — pins the preserved clean-skip behaviour for unmapped audiences. Two existing build-target tests in `tools/release/tests/test_release_build.py` were rewired to mock `build_stainless_target`; they had been silently riding on the old skip-on-missing-source behaviour and would have failed under the new contract. The functional integration is already covered by `test_build_target_calls_stainless`. No CI workflow edits, no file restructuring under `tools/stainless/`, no historical-tag backfilling. ## Test plan - [ ] Unit tests pass (`tools/release/tests/`) - [ ] Preflight passes - [ ] Manual `./build/build-release.sh --snapshot` validation produces `platform.stainless.yml` and `device.stainless.yml` under `build/dist/` --------- Co-authored-by: Claude Opus 4.7 (1M context) author: ben-miru branch: HEAD dirty: false x-build: built_at: '2026-05-06T22:31:02.715859+00:00' servers: - url: https://api.mirurobotics.com/beta description: Miru Platform API security: - ApiKeyAuth: [] paths: /config_types: parameters: - $ref: '#/components/parameters/MiruVersion' post: tags: - Config Types summary: Create description: Create a new config type. operationId: createConfigType requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/CreateConfigTypeRequest' responses: '200': description: Successfully created the config type. content: application/json: schema: $ref: '#/components/schemas/ConfigType' x-codeSamples: - lang: Python source: |- import os from miru_platform_sdk import Miru client = Miru( api_key=os.environ.get("MIRU_API_KEY"), # This is the default and can be omitted ) config_type = client.config_types.create( name="My Config Type", slug="my-config-type", ) print(config_type.id) components: parameters: MiruVersion: name: Miru-Version in: header required: true schema: type: string example: 2026-05-06.rainier description: The API version the client was built against. schemas: CreateConfigTypeRequest: title: CreateConfigTypeRequest type: object required: - name - slug properties: name: type: string description: The name of the config type. example: My Config Type slug: type: string example: my-config-type description: An immutable, code-friendly name for the config type. ConfigType: allOf: - $ref: '#/components/schemas/BaseConfigType' example: object: config_type id: cfg_typ_123 name: Motion Control slug: motion-control created_at: '2021-01-01T00:00:00Z' updated_at: '2021-01-01T00:00:00Z' created_by_id: usr_123 updated_by_id: usr_123 BaseConfigType: title: Config Type type: object required: - object - id - name - slug - created_at - updated_at properties: object: type: string enum: - config_type example: config_type x-stainless-const: true description: The object type, which is always `config_type`. id: type: string example: cfg_123 description: ID of the config type. name: type: string example: My Config Type description: Name of the config type. slug: type: string example: my-config-type description: An immutable, code-friendly name for the config type. created_at: type: string format: date-time example: '2021-01-01T00:00:00Z' description: Timestamp of when the config type was created. updated_at: type: string format: date-time example: '2021-01-01T00:00:00Z' description: Timestamp of when the config type was last updated. securitySchemes: ApiKeyAuth: type: apiKey in: header name: X-API-Key description: The API key to use for authentication. ````