Vendor API capability matrix

Use this matrix when discussing an integration with a vendor. Confirm product versions, licensing, access programmes and supported operations for the intended deployment.

Overview#

This reference defines how to compare vendor APIs. It intentionally doesn't duplicate fast changing vendor capability claims. Use the maintained vendor API catalogue and its selection and capability matrix for source backed vendor rows, then open each vendor page and current official documentation.

Why the matrix stays generic#

A single check mark such as “events,” “video,” or “access control” hides the facts that decide compatibility:

• exact product family/build/firmware and API/SDK release;
• deployment model, region, tenant, licence, partner program, and feature entitlement;
• operation direction and authoritative system;
• resource granularity, security identity, scope, and role;
• delivery, pagination, rate, queue, retention, and reconciliation behaviour;
• deprecation, support, distribution, and legal/licensing terms;
• whether an operation observes, configures, or physically actuates.

Therefore this page carries no vendor rows. A populated row belongs beside its official sources in 04-vendor-apis, not as an uncited summary here.

One row per exact surface#

Don't create one row per marketing brand. Create a row only for an interface with a documented scope:

vendor / publisher:
product family and deployment:
API, SDK, plug-in framework, or protocol surface:
exact API/SDK/document version:
supported product/server/firmware window:
region/tenant/licence/partner prerequisites:
official reference and access date:
release/lifecycle source and access date:
canonical vendor page:
evidence grade and coverage limit:

If a public landing page establishes that a surface exists but the normative contract is gated, record that limitation. Don't reverse engineer a capability cell from marketing copy, UI screenshots, package names, forum posts, or an SDK class list.

Comparison dimensions#

Deployment and authority#

Access and entitlement#

Access to documentation isn't runtime entitlement. A customer login isn't permission to redistribute a licensed SDK, and a downloaded SDK isn't proof of compatibility with an installed product.

Identity and security#

Capability classes#

Use these only as headings for evidence, never yes/no marketing cells:

For any physical control class, attach the safety impact checklist. “Unlock available” without preconditions, exact authorisation, completion feedback, timeout behaviour, and qualified owner approval isn't a useful capability claim.

Evidence states for a cell#

Never encode unknown as no. Never promote a vendor documentation claim to environment validated. A product can support an API family while omitting a method, model, event, role, or security mode.

Suggested populated table contract#

The canonical vendor section may use several tables rather than one extremely wide table. Each row should be reducible to:

Shortlisting questions#

• Does the surface exist for the exact installed deployment, build, model, licence, region, and role?
• Is its normative contract accessible under acceptable terms for development, deployment, and maintenance?
• Is it authoritative for the desired data/action, or a cache/proxy with weaker semantics?
• Can observation, configuration, administration, credential, media, and physical command privileges be separated?
• Are stable IDs, schema/version, pagination, event replay, reconciliation, and deletion semantics documented?
• Are timeout/retry/duplicate/unknown outcome rules safe for every mutating operation?
• Are quotas, concurrency, retention, export, and failure/recovery limits available and owner testable?
• Are certificates/secrets/tokens/callbacks manageable throughout deployment and offboarding?
• Are release notes, deprecation notices, security advisories, compatibility matrices, and support paths durable?
• Is a standards based surface preferable or required, and is the exact product/profile registered/certified?
• Can the integration team validate it with synthetic data in an isolated authorised environment without physical consequence?

Related pages#

• Vendor API catalogue
• Vendor API selection and capability matrix
• Integration readiness checklist
• API and event security
• Retries, timeouts, and idempotency
• Polling, subscriptions, and state reconciliation
• Contribution guide

Section overview · Wiki home