Texture OEM / TPDO Integration Technical Requirements
Version: 1.0 Last Updated: November 2025 Contact: integrations@texturehq.com
Executive Summary
Texture provides a unified platform for device connectivity, telemetry ingestion, and real-time control of distributed energy resources (DERs).
This specification defines the technical requirements for:
- OEMs (device manufacturers), and
- TPDOs (Third-Party Device Operators — entities that operate, manufacture, or aggregate devices and expose them via an API)
integrating their devices with the Texture platform.
These requirements are device-type agnostic. Different device classes (batteries, solar inverters, EV chargers, thermostats, etc.) have different telemetry and control surfaces. The canonical field-level schemas for each device type are defined in Texture's API documentation. This spec describes the integration patterns and expectations for accessing and controlling those devices via an OEM or TPDO API.
Integrations must be reliable, secure, and capable of supporting fleet-scale telemetry and dispatch.
1. Scope and Device Types
Texture supports multiple device classes, including but not limited to:
- Whole-home and C&I battery systems
- Solar inverters and hybrid inverter systems
- EV charging equipment
- Smart thermostats and HVAC controls
- Other controllable DERs exposed via OEM or TPDO APIs
For any given integration, Texture and the OEM/TPDO will agree on which Texture device models apply (e.g., battery, inverter, thermostat) and map the OEM/TPDO's data to those models.
Field-level schemas for each device class are defined in Texture's API documentation. This spec focuses on transport, freshness, control semantics, and performance—not enumerating every field for every device type.
2. Integration Patterns
There are three primary ways devices integrate with Texture:
2.1 Texture-led ("Pull") Integrations
In this pattern, Texture implements the integration:
- Texture reads the OEM/TPDO's API documentation.
- Texture implements polling against the OEM/TPDO API.
- Texture performs device discovery (e.g., list sites → list devices) and creates internal device records.
- Texture translates OEM-specific telemetry and commands into Texture's standard device models.
OEMs/TPDOs typically do not need to build anything new; Texture does the implementation work.
2.2 Partner-led ("Push / Programmatic") Integrations
In this pattern, the OEM/TPDO takes a more active role:
- OEM/TPDO exposes APIs or event streams Texture subscribes to.
- OEM/TPDO assists with device identification and registration.
- OEM/TPDO implements push-first behaviors (e.g., telemetry pushed to Texture).
Partner-led integrations allow faster onboarding when OEMs/TPDOs have well-documented, reliable APIs that meet this spec's requirements.
2.3 Texture-native Integrations
In this pattern, the OEM/TPDO has already pointed their devices and/or API data to Texture:
- Texture already captures all telemetry data directly from devices or the OEM/TPDO's systems.
- The OEM/TPDO only needs to respond to control signals from Texture.
- In some cases, Texture handles control as well, communicating directly with device endpoints on behalf of the OEM/TPDO.
Texture-native integrations provide the tightest coupling and fastest response times for grid services.
Regardless of pattern, OEMs/TPDOs must meet the freshness, reliability, and control expectations defined in this document.
3. Authentication & Authorization
Texture requires programmatic access to:
- Read telemetry for authorized devices
- Send control/dispatch requests to those devices
The specific auth mechanism (OAuth2, API key, service account) can vary by OEM/TPDO. What matters is that it is secure, automatable, and appropriately scoped.
We distinguish integrations by who is granting authorization, not by which auth protocol is used.
3.1 End-User Authorized (BYOD)
Used when the end customer (homeowner, business) owns the device and explicitly grants Texture access.
OAuth 2.0 is the preferred authorization method. Texture will never store end-user username/password credentials, as this is inherently insecure. Access must be granted through a delegated authorization flow that provides an explicit grant the end user can revoke.
Requirements:
- OAuth 2.0 Authorization Code flow (or equivalent delegated authorization mechanism).
- End user can grant Texture access to read device information/telemetry and send allowable control commands.
- Access can be revoked by the end user at any time.
- Long-lived access is supported via refresh tokens (≥90 days recommended).
- The OEM/TPDO defines the actual scopes/permissions; Texture will request the minimal set needed to discover devices, read telemetry, and issue control commands.
3.2 Utility or Program-Authorized Access
Used when a utility, CCA, or program administrator is the effective owner/operator of a fleet of devices.
Requirements:
- Programmatic access to telemetry and control for enrolled devices via OAuth2 (client credentials) or API keys/service accounts with clear scoping.
- Ability to onboard devices in bulk (by program, site, account, etc.).
- Ability to revoke or adjust access by program/portfolio.
3.3 Fleet Owner / Third-Party Device Operator (TPDO)
Used when a fleet owner, installer, aggregator, or TPDO manages devices for many end customers.
Requirements:
- Programmatic access via OAuth2 or API key/service account.
- Fleet-level querying of devices and metadata.
- Bulk operations (e.g., "all devices in portfolio X").
- Stable device identifiers (no churn on IDs).
Any TPDO that aggregates multiple OEMs must ensure all devices they expose to Texture meet the freshness, reliability, and control expectations in this spec.
4. Telemetry Requirements
Texture requires fresh, structured telemetry for all enrolled devices at a cadence that supports grid operations and program logic.
4.1 Delivery Patterns
Push (Preferred)
OEM/TPDO sends events to Texture when data changes or at specified intervals via:
- Webhooks / HTTP callbacks
- WebSockets / streaming
- MQTT, Kafka, or equivalent
Requirements:
- Data delivered in near real time or on a consistent schedule.
- Retries on transient failure.
- Reasonable backoff and idempotency or deduplication support.
Polling (Fallback)
Texture calls OEM/TPDO APIs on a schedule to fetch telemetry.
Requirements:
- Support polling at 5–15 minute intervals.
- Data returned must reflect current device state, not stale batch-processed data.
- Data freshness must be < 15 minutes.
- API response latency: p95 < 2 seconds.
4.2 Telemetry Expectations
For every device type integrated with Texture, OEMs/TPDOs must provide:
- A stable device identifier and associated metadata.
- Time-stamped telemetry fields that map to Texture's device models.
Examples (illustrative):
- Batteries: state of charge, charge/discharge power, available energy, connection/health status
- Solar inverters: real power output, grid connection state, export/import, per-phase metrics
- Thermostats/HVAC: current temperature, setpoint(s), mode, fan state, system on/off
The authoritative field list per device type is in Texture's API documentation.
5. Control & Dispatch Requirements
Control surfaces vary by device type. How control is executed depends on the integration pattern:
Texture-led integrations: Texture translates control requests into OEM/TPDO-specific API calls and hits their endpoints directly to actuate commands.
Partner-led integrations: Texture issues a standardized control signal. The OEM/TPDO transforms it into their own command format and actuates it on the device.
Texture-native integrations: Texture handles everything end-to-end, contacting device endpoints directly for dispatch without requiring OEM/TPDO intervention.
5.1 General Control Requirements
OEMs/TPDOs must:
- Provide documented control endpoints or operations.
- Return clear acknowledgment that a command was accepted or rejected.
- Provide a way to query command status (pending, in-progress, complete, failed).
- Return actionable error information for failed commands.
Control may be synchronous or asynchronous, but the behavior must be documented and consistent.
5.2 Device-Type Specific Control
Command sets differ by device:
- Battery systems: set charge/discharge power or mode, set import/export to/from the grid, set backup reserve
- Solar inverters: limit export, curtailment commands, power factor adjustments
- Thermostats: set setpoints, HVAC mode, fan mode, schedule overrides
For any device class claimed to be controllable via Texture, OEMs/TPDOs must expose a control surface sufficient to implement agreed use cases (demand response, TOU shifting, VPP dispatch).
5.3 Control Safety Requirements
The control surface exposed via API must be designed to be safe and must not allow commands that could cause harm to the device, property, or persons.
Requirements:
- Control commands must operate within manufacturer-specified safe operating limits.
- APIs must reject or constrain commands that could damage equipment (e.g., overcharging a battery beyond rated capacity, running HVAC systems outside safe parameters).
- OEMs/TPDOs are responsible for implementing appropriate safeguards at the device or cloud level to prevent unsafe operations, regardless of what commands are received via API.
6. Historical Metrics
Historical data supports reconciliation, settlement, program analytics, and reporting.
Requirements:
- OEMs/TPDOs must expose endpoints or reports where Texture can retrieve historical telemetry for enrolled devices.
- Up to 90 days of history is required where available (newly installed devices may have less).
- Granularity: 5-minute, 15-minute, or hourly depending on device type and integration.
- Historical endpoints must support pagination or batching.
- Query performance: p95 ≤ 10 seconds for reasonable date ranges.
7. Performance, Reliability, and Rate Limits
7.1 Availability
Requirements:
- 99.5%+ uptime for production APIs.
- 48 hours advance notice for planned maintenance where feasible.
- Status page or equivalent channel for outage communication (strongly recommended).
7.2 Rate Limits
Rate limits must support fleet-scale workloads:
- Telemetry polling for all enrolled devices at 5–15 minute intervals.
- Control bursts during DR/VPP events.
- Historical export for portfolios without throttling into unusability.
Rate limits must be:
- Documented per endpoint category (telemetry / control / historical / metadata).
- Scaled to portfolio size or adjustable via coordination with Texture.
7.3 Performance Targets
| Category | Required p95 Latency |
|---|---|
| Telemetry requests | < 2 seconds |
| Control acknowledgments | < 3 seconds |
| Historical queries | < 10 seconds |
8. Documentation & Developer Experience
OEMs/TPDOs must provide:
- API reference (REST or GraphQL), preferably with OpenAPI/Swagger schema.
- Authentication guide.
- Examples for common telemetry and control flows.
- Clear description of device discovery (how Texture finds devices for a given customer/program).
- Documentation of rate limits.
- Versioning and changelog policy.
A sandbox or test environment is strongly recommended.
9. Security & Privacy
Transport & Access Control
- All APIs served over HTTPS with modern TLS.
- API keys, client secrets, and tokens must be rotatable without downtime.
- Production APIs require authentication (no anonymous endpoints for device data/control).
Data Handling & Privacy
- OEMs/TPDOs must comply with applicable privacy regulations (e.g., GDPR, CCPA where relevant).
- Documented process for de-provisioning access for a device or account.
- Documented process for handling data deletion requests.
10. Device Identification & Mapping
Regardless of integration pattern, Texture requires stable device identification.
Requirements:
- Each device has a stable unique ID that does not change over time.
- OEMs/TPDOs provide sufficient metadata to:
- Identify device type (battery, inverter, thermostat, etc.)
- Associate device to a customer/site/account
- Map to Texture's internal models
11. Certification Process
OEMs/TPDOs seeking integration with Texture should contact integrations@texturehq.com to begin the process. The Texture team will work with you to:
- Review your API documentation and capabilities.
- Validate telemetry and control requirements against this spec.
- Test the integration in a staging environment.
- Certify the integration for production use.