Current Limitations of the NIM Metadata API
The following constraints apply to the NIM Metadata API today, so you can plan around them. For the fields these constraints refer to, refer to Response Fields.
Coverage
Coverage is partial and growing. Metadata is attached at publish time, so NIM microservices released before this API launched in September 2026 generally lack metadata until they are republished. Design for a 404 status code as a normal outcome rather than an error.
Planned Field-Shape Changes
The gpu and gpu_device fields can become arrays. A single profile can be
valid on several compatible GPUs, which the current single-string fields cannot
express.
To make that change a non-event for your integration, write your parser to accept either a string or a list now. For the pattern, refer to rule 4 in Notes for Automated Agents.
Unstandardized and Optional Fields
The following table describes fields you should treat with care:
Caching
The API offers no ETag header, no Last-Modified header, and no conditional-request support. Cache based on tag stability instead, as described in Notes for Automated Agents.
Best Practices
Apply the following practices to work within these constraints:
- Treat a 404 status code as data, not failure. It is a definitive answer about metadata availability.
- Parse permissively. Accept unrecognized keys and both shapes of the GPU fields.
- Rank on fields with defined semantics. Use
min_vram_per_device_gband parallelism sizes rather thanthroughputwhen comparing NIM microservices. - Verify entitlement separately. An absent
allowed_deployment_regionsvalue means no recorded restriction, so confirm license terms rather than inferring them from absence.