Virtual Peaker is a Louisville, Kentucky software company selling grid-edge DERMS and virtual power plant software to United States and Canadian electric utilities — investor-owned utilities, municipal utilities, and rural electric cooperatives. Its platform is sold as three suites: Shift (grid-edge DERMS device control and demand response event dispatch), Relay (customer engagement, enrollment, and incentive processing), and Envision (demand forecasting). Virtual Peaker sits in the private DER-orchestration layer of the energy value chain, between device OEMs behind the meter and the utility back office — it is a vendor, not a utility, not a retailer, and not a data holder, so no consumer energy data right attaches to it. There is no Green Button / ESPI implementation here, no Consumer Data Right obligation, and no open market or grid data of any kind. What it does publish is its own API specification: Gravity Connect, an OpenAPI 3.0.0 contract (v2.0.6) that Virtual Peaker authored and openly published as a vendor-agnostic alternative to OpenADR and IEEE 2030.5 for onboarding and controlling DER devices. Gravity Connect is two-sided — the device OEM implements one half, the VPP platform implements the other — and both halves are readable anonymously as full Redoc API references. The honest posture: a real, downloadable, standards-ambitious API contract that is effectively undiscoverable (it is linked from nowhere on the marketing site) and whose credentials are partner-only, issued per utility program by emailing the Gravity Connect team. The commercial Shift API is named and sold on the marketing site but has no public documentation at all.
Virtual Peaker publishes 8 API contracts indexed on the APIs.io network, including Commands API, Devices API, Energy Interval Endpoint API, and 5 more. Tagged areas include Energy, United States, Utilities, Electricity, and Grid.
The Virtual Peaker catalog on APIs.io includes 1 event-driven AsyncAPI specification and 1 Spectral governance ruleset.
Virtual Peaker’s developer surface includes authentication, documentation, API reference, engineering blog, support, getting-started guide, changelog, and 30 more developer resources.
48.1/100developing▬ flatAgent30/100agent readyFront door AI4/6
moderate
Heartbeat100/100
alive
saas
Full breakdown ↓
scored 2026-11-06 · rubric v0.27.0 · Show this score on your site →
Regulatory Posture applies to this provider. Its tags matched the
Energy & Utilities regime, so
Regulatory Posture carries 15 points of the composite.
If this regime is wrong for your business, say so on your
provider repo — the
applicability map is public and we will correct it.
Create-or-Update Ergonomics applies to this provider. This API accepts writes, so it
carries 10 points of the composite. It is scored from the published contracts
themselves: whether a caller can create-or-update in one call, whether the write accepts a key the caller already
holds, and whether the response says which branch ran. Without that, every write needs a search-and-branch in
front of it, and the first time that check is skipped a duplicate record is created.
Scored against the observed mean rather than raw — a provider at the catalog average is unchanged by this facet,
not penalised by it.
The six quality facets above are damped to 75 points between them,
because the conditional facet above carries the other
25. That is why each facet's contribution is shown against a damped
maximum: raising a quality facet moves the composite by 75% of its nominal
weight, not 100%. The full arithmetic is at apis.io/rating/.
Show this score on your site.
It updates itself when the score changes. Paste this where you link to your API docs:
<a href="https://apis.io/providers/virtual-peaker/"><img src="https://apis.io/badge/virtual-peaker/card.svg" alt="Virtual Peaker on APIs.io — Kin Score by API Evangelist"></a>
Other styles, a README pill and a shields.io endpoint are on the badge page.
Raise your score.
Agent readiness — checks not met, largest first (exact, from this profile):
MCP Server+12 pts — deployment.mode + probe verdict on the mcp/ manifest, not the pointer; an unprobed slug falls back to authorship
Idempotency+9 pts — OpenAPI mutating operations declare an idempotency key — a header, a request-body property, or a named de-duplication token whose own description says so (verified); else common[].type matches /idempoten/i (documented)
A2A Agent Card+8 pts — a2a/-a2a.yml manifest, graded on conformance.grade against A2A 1.0.0
Rate-Limit Signaling+7 pts — OpenAPI responses document X-RateLimit-* / RateLimit headers (verified), else a rate_limits artifact or RateLimits link (documented)
Pagination+5 pts — share of collection GETs (an array, or one wrapped in data/items/results ...) that declare a page/limit/offset/cursor parameter, a Link header or a next/cursor field; na with no collection GETs
5 more unmet checks in the Agent Readiness table above.
Kin Score — facets with the most composite points still available (weight × headroom):
Access Clarityscores 27.6 — up to +14.5 composite points
The Kin Score Market layer reads a provider inside its market:
its position, and how deep its integrations go. Depth is only comparable within a position. Provisional and unweighted:
not part of the Kin Score or agent readiness.
Registered MCP server and declares compatibility are report only — not weighted.
Undeclared means we found nothing we can read, so there is no number: we never infer integrations.
Standards this provider implements or carries. De facto ones are profiled and measured by the API Commons; formal ones come from the standards directory and are linked by the provider's own tags. The evidence column says how each claim was established — not that it was made.
Virtual Peaker supports managing groups of devices, in addition to individual device control. Grouping enables utilities to target clusters of devices together in demand respons...
The OAuth device discovery flow works as follows: 1. The device owner fills out an onboarding form on Virtual Peaker's site. 2. At the end of the form, we redirect them to the D...
The [pairing code](./device-partner-api.html#section/Pairing-Codes) device discovery flow works as follows: 1. The device owner fills out an onboarding form on Virtual Peaker's ...
The utility commissioned [pairing code](./device-partner-api.html#section/Pairing-Codes) flow could work as follows: 1. The device owner fills out an onboarding form on Virtual ...
All of the endpoints below allow the Device Partner to publish data to the Virtual Peaker platform, which avoids Virtual Peaker having to constantly poll the data when there hav...
Overlays applied on top of this provider's contracts. Each card says who wrote it: a document the provider publishes, or one API Evangelist derived or generated.
aid: virtual-peaker
url: https://raw.githubusercontent.com/api-evangelist/virtual-peaker/refs/heads/main/apis.yml
name: Virtual Peaker
kind: company
description: 'Virtual Peaker is a Louisville, Kentucky software company selling grid-edge DERMS and virtual power plant software
to United States and Canadian electric utilities — investor-owned utilities, municipal utilities, and rural electric cooperatives.
Its platform is sold as three suites: Shift (grid-edge DERMS device control and demand response event dispatch), Relay (customer
engagement, enrollment, and incentive processing), and Envision (demand forecasting). Virtual Peaker sits in the private
DER-orchestration layer of the energy value chain, between device OEMs behind the meter and the utility back office — it
is a vendor, not a utility, not a retailer, and not a data holder, so no consumer energy data right attaches to it. There
is no Green Button / ESPI implementation here, no Consumer Data Right obligation, and no open market or grid data of any
kind. What it does publish is its own API specification: Gravity Connect, an OpenAPI 3.0.0 contract (v2.0.6) that Virtual
Peaker authored and openly published as a vendor-agnostic alternative to OpenADR and IEEE 2030.5 for onboarding and controlling
DER devices. Gravity Connect is two-sided — the device OEM implements one half, the VPP platform implements the other —
and both halves are readable anonymously as full Redoc API references. The honest posture: a real, downloadable, standards-ambitious
API contract that is effectively undiscoverable (it is linked from nowhere on the marketing site) and whose credentials
are partner-only, issued per utility program by emailing the Gravity Connect team. The commercial Shift API is named and
sold on the marketing site but has no public documentation at all.'
deliveryModel:
model: saas
open_source: false
commercial: true
callable_host: true
label: Hosted service · you call their endpoint
confidence: high
source:
- openapi
- pricing
generated: '2026-08-28'
method: derived
accessModel:
pricing: unknown
onboarding: self-serve
trial: false
try_now: false
public: false
gated: none
gated_source:
- onboarding
label: Self-serve signup
confidence: medium
source:
- authentication
- security
- sandbox
generated: '2026-11-06'
method: derived
image: https://assets.virtualpeaker.io/gravity-connect/assets/vp_logo.png
tags:
- Energy
- United States
- Utilities
- Electricity
- Grid
- Demand Response
- DER
- DERMS
- Virtual Power Plant
- EV Charging
- Smart Thermostats
- Energy Storage
created: '2026-07-27'
modified: '2026-07-27'
enrichment:
round: '2026-07-27'
method: search/generate/derive
notes: 'Round 2 enrichment. Contract discovery re-run against every host (partner.virtualpeaker.io, partner-dev.virtualpeaker.io,
assets.virtualpeaker.io, virtual-peaker.com, support.virtual-peaker.com): no additional OpenAPI, no GraphQL, no MCP server,
no AsyncAPI and no /.well-known/ surface exist. New finds this round: the publicly downloadable Gravity Connect Postman
collection and the partner-dev environment it points at.'
specificationVersion: '0.23'
apis:
- aid: virtual-peaker:virtual-peaker-commands-api
name: Virtual Peaker Commands API
description: Command specific endpoints
humanURL: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html
baseURL: https://partner.virtualpeaker.io/v1
tags:
- Commands
properties:
- type: OpenAPI
url: openapi/virtual-peaker-commands-api-openapi.yml
- type: APIReference
url: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html
- type: Documentation
url: https://virtual-peaker.com/partners/device-partners/
- type: Blog
url: https://virtual-peaker.com/blog/gravity-connect-api-oem-derms-integrations/
- type: GettingStarted
url: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html#section/Getting-Started
- type: APIReference
url: https://assets.virtualpeaker.io/gravity-connect/vp-api.html
- type: Documentation
url: https://virtual-peaker.com/apis/
- type: Blog
url: https://virtual-peaker.com/blog/gravity-connect-v-openadr/
- type: Webhooks
url: asyncapi/virtual-peaker-gravity-connect-webhooks.yml
- aid: virtual-peaker:virtual-peaker-devices-api
name: Virtual Peaker Devices API
description: Device specific endpoints
humanURL: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html
baseURL: https://partner.virtualpeaker.io/v1
tags:
- Devices
properties:
- type: OpenAPI
url: openapi/virtual-peaker-devices-api-openapi.yml
- type: APIReference
url: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html
- type: Documentation
url: https://virtual-peaker.com/partners/device-partners/
- type: Blog
url: https://virtual-peaker.com/blog/gravity-connect-api-oem-derms-integrations/
- type: GettingStarted
url: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html#section/Getting-Started
- type: APIReference
url: https://assets.virtualpeaker.io/gravity-connect/vp-api.html
- type: Documentation
url: https://virtual-peaker.com/apis/
- type: Blog
url: https://virtual-peaker.com/blog/gravity-connect-v-openadr/
- type: Webhooks
url: asyncapi/virtual-peaker-gravity-connect-webhooks.yml
- aid: virtual-peaker:virtual-peaker-energy-interval-endpoint-api
name: Virtual Peaker Energy Interval Endpoint API
description: The Energy Interval Endpoint API from Virtual Peaker — 1 operation(s) for energy interval endpoint.
humanURL: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html
baseURL: https://partner.virtualpeaker.io/v1
tags:
- Energy Interval Endpoint
properties:
- type: OpenAPI
url: openapi/virtual-peaker-energy-interval-endpoint-api-openapi.yml
- type: APIReference
url: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html
- type: Documentation
url: https://virtual-peaker.com/partners/device-partners/
- type: Blog
url: https://virtual-peaker.com/blog/gravity-connect-api-oem-derms-integrations/
- type: GettingStarted
url: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html#section/Getting-Started
- type: APIReference
url: https://assets.virtualpeaker.io/gravity-connect/vp-api.html
- type: Documentation
url: https://virtual-peaker.com/apis/
- type: Blog
url: https://virtual-peaker.com/blog/gravity-connect-v-openadr/
- type: Webhooks
url: asyncapi/virtual-peaker-gravity-connect-webhooks.yml
- aid: virtual-peaker:virtual-peaker-group-management-api
name: Virtual Peaker Group Management API
description: "Virtual Peaker supports managing groups of devices, in addition to individual device control. Grouping enables\
\ utilities to target clusters of devices together in demand response events.While device telemetry and configuration\
\ data is still reported on a per-device level, groups allow a single command to be broadcast to multiple enrolled devices\
\ simultaneously.\nTo utilize grouping, the Device Partner integration must support both individual and group commands\
\ concurrently. The same device could receive an individual command, while also belonging to a group receiving a separate\
\ directive.\nGroup commands have additional considerations:\n 1. Devices can opt out of group events individually, while\
\ the overall group command remains active.\n 2. Group command statuses reflect execution at the scheduling engine level\
\ rather than device state.\n 3. The Device Partner must reconcile group vs. individual state to ensure consistency in\
\ reporting.\n\nWhen not specified, all other workflows behave identically between individual and grouped devices - enrollment,\
\ data publishing, cancellations, etc."
humanURL: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html
baseURL: https://partner.virtualpeaker.io/v1
tags:
- Group Management
properties:
- type: OpenAPI
url: openapi/virtual-peaker-group-management-api-openapi.yml
- type: APIReference
url: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html
- type: Documentation
url: https://virtual-peaker.com/partners/device-partners/
- type: Blog
url: https://virtual-peaker.com/blog/gravity-connect-api-oem-derms-integrations/
- type: GettingStarted
url: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html#section/Getting-Started
- type: APIReference
url: https://assets.virtualpeaker.io/gravity-connect/vp-api.html
- type: Documentation
url: https://virtual-peaker.com/apis/
- type: Blog
url: https://virtual-peaker.com/blog/gravity-connect-v-openadr/
- type: Webhooks
url: asyncapi/virtual-peaker-gravity-connect-webhooks.yml
- aid: virtual-peaker:virtual-peaker-oauth-device-discovery-preferred-api
name: Virtual Peaker OAuth Device Discovery (Preferred) API
description: 'The OAuth device discovery flow works as follows:
1. The device owner fills out an onboarding form on Virtual Peaker''s site.
2. At the end of the form, we redirect them to the Device Partner''s OAuth authorization page via a link.
3. The user logs into the Device Partner''s app and grants OAuth access permissions.
4. The Device Partner app completes OAuth authorization code flow, exchanging the code for an access token.
5. Using the access token, the Device Partner calls their API to retrieve the user''s devices.
6. The Device Partner associates the devices with the correct Virtual Peaker program in their backend.
7. The Device Partner handles any additional onboarding logic in their system.
8. The Device Partner publishes enrolled device data to Virtual Peaker''s API.
9. Virtual Peaker discovers devices using the OAuth token provided.
10. We subscribe to devices for data publishing and provide a DEVICE_PUBLISH_SECRET.
11. Virtual Peaker may optionally pull initial device data from the Device Partner''s API.
For each utility program, a separate client_id is created.
This ID is passed in the OAuth link to associate devices with the correct program.'
humanURL: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html
baseURL: https://partner.virtualpeaker.io/v1
tags:
- OAuth Device Discovery (Preferred)
properties:
- type: OpenAPI
url: openapi/virtual-peaker-oauth-device-discovery-preferred-api-openapi.yml
- type: APIReference
url: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html
- type: Documentation
url: https://virtual-peaker.com/partners/device-partners/
- type: Blog
url: https://virtual-peaker.com/blog/gravity-connect-api-oem-derms-integrations/
- type: GettingStarted
url: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html#section/Getting-Started
- type: APIReference
url: https://assets.virtualpeaker.io/gravity-connect/vp-api.html
- type: Documentation
url: https://virtual-peaker.com/apis/
- type: Blog
url: https://virtual-peaker.com/blog/gravity-connect-v-openadr/
- type: Webhooks
url: asyncapi/virtual-peaker-gravity-connect-webhooks.yml
- aid: virtual-peaker:virtual-peaker-pairing-code-device-discovery-end-user-app-api
name: Virtual Peaker Pairing Code Device Discovery - End User App API
description: 'The [pairing code](./device-partner-api.html#section/Pairing-Codes) device discovery flow works as follows:
1. The device owner fills out an onboarding form on Virtual Peaker''s site.
2. At the end of the form, we provide them with a pairing code and instructions to enter it in the Device Partner''s app.
3. Optionally, the user selects which devices to enroll via the Device Partner''s interface. Otherwise, all devices are
enrolled by default.
4. When the user enters the pairing code in the Device Partner''s app, the Device Partner publishes a device enrollment
event to Virtual Peaker''s API.
5. The publish event includes the pairing code, allowing Virtual Peaker to link the device back to the onboarding form
entry.
6. If multiple devices are enrolled, the same pairing code is used in each publish payload.
7. Virtual Peaker discovers the user details associated with the enrolled device(s).
8. We subscribe to the devices for data publishing and provide a `DEVICE_PUBLISH_SECRET`.
The user experience is driven through the Device Partner''s web or mobile app after receiving the pairing code. This links
together the Virtual Peaker and Device Partner platforms.'
humanURL: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html
baseURL: https://partner.virtualpeaker.io/v1
tags: []
tags_raw:
- Pairing Code Device Discovery - End User App
properties:
- type: OpenAPI
url: openapi/virtual-peaker-pairing-code-device-discovery-end-user-app-api-openapi.yml
- type: APIReference
url: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html
- type: Documentation
url: https://virtual-peaker.com/partners/device-partners/
- type: Blog
url: https://virtual-peaker.com/blog/gravity-connect-api-oem-derms-integrations/
- type: GettingStarted
url: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html#section/Getting-Started
- type: APIReference
url: https://assets.virtualpeaker.io/gravity-connect/vp-api.html
- type: Documentation
url: https://virtual-peaker.com/apis/
- type: Blog
url: https://virtual-peaker.com/blog/gravity-connect-v-openadr/
- type: Webhooks
url: asyncapi/virtual-peaker-gravity-connect-webhooks.yml
- aid: virtual-peaker:virtual-peaker-pairing-code-device-discovery-utility-commissioned-installation-api
name: Virtual Peaker Pairing Code Device Discovery - Utility Commissioned Installation API
description: 'The utility commissioned [pairing code](./device-partner-api.html#section/Pairing-Codes) flow could work as
follows:
1. The device owner fills out an onboarding form on Virtual Peaker''s site.
2. The utility reviews the submission and approves it if eligible.
3. Virtual Peaker informs the Device Partner of the install address and provides a pairing code.
4. The Device Partner takes necessary actions to install and activate the device on-site.
5. When installation is complete, the Device Partner publishes a device enrollment event to Virtual Peaker.
6. The publish includes the pairing code to link with the onboarding form.
7. If multiple devices are installed, the same code is used in each payload.
8. Virtual Peaker discovers user details for the enrolled device(s).
9. We subscribe to the device(s) for data publishing and provide a `DEVICE_PUBLISH_SECRET`.
In this flow, the utility directs the installation. The pairing code links the user signup, Device Partner platform, and
Virtual Peaker after install. The flow described above can have slight variations depending on the use case.'
humanURL: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html
baseURL: https://partner.virtualpeaker.io/v1
tags: []
tags_raw:
- Pairing Code Device Discovery - Utility Commissioned Installation
properties:
- type: OpenAPI
url: openapi/virtual-peaker-pairing-code-device-discovery-utility-commissioned-installation-api-openapi.yml
- type: APIReference
url: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html
- type: Documentation
url: https://virtual-peaker.com/partners/device-partners/
- type: Blog
url: https://virtual-peaker.com/blog/gravity-connect-api-oem-derms-integrations/
- type: GettingStarted
url: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html#section/Getting-Started
- type: APIReference
url: https://assets.virtualpeaker.io/gravity-connect/vp-api.html
- type: Documentation
url: https://virtual-peaker.com/apis/
- type: Blog
url: https://virtual-peaker.com/blog/gravity-connect-v-openadr/
- type: Webhooks
url: asyncapi/virtual-peaker-gravity-connect-webhooks.yml
- aid: virtual-peaker:virtual-peaker-publishing-api
name: Virtual Peaker Publishing API
description: 'All of the endpoints below allow the Device Partner to publish data to the Virtual Peaker platform, which
avoids Virtual Peaker having to constantly poll the data when there haven''t been any changes. Part of the [Device Partner
Implementation](example.com) does include endpoint to read poll for data, which could be used by Virtual Peaker to gather
the first batch of data or for debugging.
**Notes:**
- The maximum supported payload size for all requests listed below is 262,144 bytes.'
humanURL: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html
baseURL: https://partner.virtualpeaker.io/v1
tags:
- Publishing
properties:
- type: OpenAPI
url: openapi/virtual-peaker-publishing-api-openapi.yml
- type: APIReference
url: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html
- type: Documentation
url: https://virtual-peaker.com/partners/device-partners/
- type: Blog
url: https://virtual-peaker.com/blog/gravity-connect-api-oem-derms-integrations/
- type: GettingStarted
url: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html#section/Getting-Started
- type: APIReference
url: https://assets.virtualpeaker.io/gravity-connect/vp-api.html
- type: Documentation
url: https://virtual-peaker.com/apis/
- type: Blog
url: https://virtual-peaker.com/blog/gravity-connect-v-openadr/
- type: Webhooks
url: asyncapi/virtual-peaker-gravity-connect-webhooks.yml
common:
- type: CapabilityMap
url: capabilities/virtual-peaker-capability-edges.yml
name: Virtual Peaker Business Capability Map
- type: Overlay
url: overlays/virtual-peaker-gravity-connect-device-partner-api-overlay.yaml
- type: Overlay
url: overlays/virtual-peaker-gravity-connect-vpp-api-overlay.yaml
- type: X-MCPServerCandidate
url: mcp/virtual-peaker-mcp.yml
note: 'Renamed from MCPServer 2026-09-03 (roadmap#247): the manifest self-describes as status: candidate — a tool list derived
from the published API contracts, not an existing server. The scorer already read the manifest and reported mcp_server
correctly; the MCPServer type was crediting the artifact-type surfaces with a server that does not exist.'
- type: AgenticAccess
url: agentic-access/virtual-peaker-agentic-access.yml
- type: DomainSecurity
url: security/virtual-peaker-domain-security.yml
- type: OAuthScopes
url: scopes/virtual-peaker-scopes.yml
- type: Authentication
url: authentication/virtual-peaker-authentication.yml
- type: Website
url: https://virtual-peaker.com/
- type: Documentation
url: https://virtual-peaker.com/apis/
- type: APIReference
url: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html
- type: Blog
url: https://virtual-peaker.com/blog/
- type: BlogRSS
url: https://virtual-peaker.com/feed/
- type: Support
url: https://support.virtual-peaker.com/knowledge
- type: SupportCenter
url: https://support.virtual-peaker.com/knowledge
- type: GitHubOrganization
url: https://github.com/virtual-peaker
- type: LinkedIn
url: https://www.linkedin.com/company/virtual-peaker/
- type: PrivacyPolicy
url: https://virtual-peaker.com/privacy-policy/
- type: TermsOfService
url: https://virtual-peaker.com/terms-of-use/
- type: ContactForm
url: https://virtual-peaker.com/company/contact/
- type: PartnerPortal
url: https://virtual-peaker.com/partners/device-partners/
name: Device Partners — the marketing entry point for OEM integrations (the Gravity Connect references themselves are linked
from nowhere on the site)
- type: GettingStarted
url: https://assets.virtualpeaker.io/gravity-connect/device-partner-api.html#section/Getting-Started
- type: Login
url: https://utility.virtualpeaker.io/
name: Utility application sign-in (no self-serve sign-up exists)
- type: Postman
url: https://assets.virtualpeaker.io/gravity-connect/Gravity%20Connect%20API.postman_collection.json
name: Gravity Connect API Postman collection — published, anonymously downloadable, 19 requests with HMAC pre-request scripts
- type: LLMsTxt
url: https://virtual-peaker.com/llms.txt
- type: LLMsTxt
url: llms/virtual-peaker-llms.txt
- type: llmsTxt
url: https://virtual-peaker.com/llms.txt
- type: Conventions
url: conventions/virtual-peaker-conventions.yml
- type: ErrorCatalog
url: errors/virtual-peaker-problem-types.yml
- type: Lifecycle
url: lifecycle/virtual-peaker-lifecycle.yml
- type: ChangeLog
url: changelog/virtual-peaker-changelog.yml
- type: Conformance
url: conformance/virtual-peaker-conformance.yml
- type: DataModel
url: data-model/virtual-peaker-data-model.yml
- type: Sandbox
url: sandbox/virtual-peaker-sandbox.yml
name: Partner-only development environment (partner-dev.virtualpeaker.io) — no self-serve sandbox
- type: Webhooks
url: asyncapi/virtual-peaker-gravity-connect-webhooks.yml
- type: AgentSkill
url: skills/_index.yml
- type: Packages
url: packages/virtual-peaker-packages.yml
name: No first-party SDK exists in any registry — recorded as a verified negative
maintainers:
- FN: Kin Lane
email: kin@apievangelist.com
Virtual Peaker API — frequently asked questions
Does Virtual Peaker have an API?
Yes. APIs.io lists 8 APIs from Virtual Peaker, including Virtual Peaker Commands API, Virtual Peaker Devices API and Virtual Peaker Energy Interval Endpoint API, and 5 more.
Is there an OpenAPI specification for the Virtual Peaker API?
Yes. APIs.io indexes 8 OpenAPI specifications for Virtual Peaker, each linked for download from this page.
How do I authenticate with the Virtual Peaker API?
Virtual Peaker documents its authentication (oauth2/hmac · 3 schemes). The details are profiled on APIs.io as Virtual Peaker Authentication.
Is the Virtual Peaker API ready for AI agents?
Virtual Peaker has a Kin Score of 48.1 out of 100 (developing) and an Agent Readiness score of 29.7 (agent-ready), scored by API Evangelist on 2026-11-06.
Calls without X-API-Key need no key. Calls with it need a paid plan — get a key.
Get an API key
Free tier, no form to fill in. Signing in shares your email address with us — we
store it to create your key and to recognise you if you sign in with another
provider. See our Privacy Policy and
Terms.
Kin Score
How this is scored →
It updates itself when the score changes. Paste this where you link to your API docs: