1. Making Your First Request

All endpoints are REST-based and return JSON.

Example request:

GET https://catalog.msp2mvp.com/api/v1/services

Example response:

[
  {
    "id": "SLI-001",
    "name": "Endpoint Patch Management",
    "category": "Endpoint & Patch Management",
    "description": "Structured patch management service covering operating systems and third-party applications."
  }
]

Responses are returned in standard JSON format with appropriate HTTP status codes.

2. Available Data Domains

The API currently exposes four logical data domains:

3. Data Structure Philosophy

Service-first, tool-second

The API is structured around a separation of concerns:

• Services are vendor-neutral and product-agnostic.
• Vendors and products are independently defined.
• Products connect to services only through mapping objects.

This allows integrators to:

• Model service coverage and value delivery
• Analyze stack alignment against a stable service framework
• Build gap analysis and catalog-driven recommendations
• Simulate service-first operating models (e.g., StackPilot-style workflows)

4. Key Definitions

4.1 Separately Licensable Product (Inclusion Rule)

Only products that meet the "separately licensable" definition are included. In practical terms, a product must be:

• Software-based (SaaS/on-prem/agent/cloud), not a service
• Independently licensable (separate SKU/billing)
• Supported by a dedicated product page/URL and clear marketing identity
• Deployable/usable as a standalone product (integrations optional)

To keep the catalog usable for MSP packaging, the dataset excludes:

• Services (MDR/SOC, training, support, professional services)
• Feature tiers and configuration variants
• Bundled modules without independent licensing
• Most infrastructure-native hyperscaler management components

4.2 Vendor & Product Description Lengths

Vendor and product records include three standardized description lengths for different use cases:

These descriptions are generated using consistent web-research prompts and then standardized for uniform tone and structure.

4.3 Product → Service Mapping Fields

supportLabel

evidenceScore

Recommended usage: Use 100/75 for automated workflows by default. Route 50/25 into review or "needs more documentation" handling.

5. HTTP Status Codes

6. Rate Limiting

There are currently no enforced rate limits in version 1.0. Clients are expected to use reasonable request patterns. Future versions may introduce rate limiting for stability.

7. Versioning

Version 1.0 represents the first public release of the catalog. The API version is embedded in the URL path:

/api/v1/

Breaking changes will result in a new version path (e.g., /api/v2/).

8. Data Freshness & Maintenance

The catalog is maintained as a structured dataset combining:

• Research-based service modeling
• AI-assisted vendor/product enrichment
• Manual validation and correction processes

Because the MSP software market changes frequently (acquisitions, rebranding, product restructuring), data may evolve over time.

We recommend:

• Avoid hard-coded assumptions
• Refresh cached data periodically
• Treat URLs/logos as best-effort fields that may change
• Monitor release notes / changelog updates

9. Feedback & Improvement

The M2M Catalog is also accessible through a web-based application powered by the same live API dataset:

Within the application, users can:

• Suggest improvements
• Report issues
• Submit content corrections

All submissions are reviewed periodically before changes are applied to the catalog dataset.

Future versions may introduce:

• Structured feedback endpoints
• Vendor-assisted data updates (with controlled mapping governance)
• Curated review and validation workflows

Governance note: if vendor self-maintenance is enabled, vendors should not manually override service mappings. Instead, vendors may upload official documentation to re-run the mapping workflow under the same methodology.