Anfragen und Antworten der Workspace-Admin-API

Dies ist die Anfrage-/Antwortreferenz jedes /v2/admin-Endpunkts. Authentifizierung, Idempotenz, Limits, Token-Erstellung und Scopes beschreibt Workspace-Admin-API. Wiederverwendbare Feldtypen und Beispiele stehen unter Schemas und Beispiele. Lesen Sie jede Zeile zusammen mit Antwort- und Fehlervertrag, der alle gemeinsamen und spezifischen Fehler-Bodys aufführt.

Gemeinsamer Vertrag

Jeder Pfad beginnt mit dem bereitgestellten Origin app-api. Der Workspace wird ausschließlich aus dem authentifizierten Token abgeleitet; Clients dürfen cpoId nicht senden. Alle dokumentierten :...Id-Ressourcenpfadwerte sind positive Dezimalzahlen ohne Nachkommastellen. Jede Anfrage benötigt genau einen:

Authorization: Bearer <workspace-access-token>

Anfragen mit JSON-Body benötigen Content-Type: application/json. Alle Änderungen erfordern Idempotency-Key (POST, PUT, PATCH und DELETE), auch POST /v2/admin/reports/send. Soweit nicht anders angegeben, ist der Erfolgs-Inhaltstyp application/json; JSON-Daten sind RFC-3339-Zeichenfolgen, Zahlen sind JSON-Zahlen.

Jede Anfrage kann X-Request-Id und X-Error-Format: envelope enthalten; siehe Antwort- und Fehlervertrag. Diese Header verändern die Erfolgsschemas nicht.

Verwendete Schreibweise:

• none bedeutet kein Request-Body. Ein DELETE mit dokumentiertem JSON-Body benötigt diesen trotzdem.
• ? kennzeichnet eine optionale Eigenschaft oder einen optionalen Query-Parameter.
• T | null bedeutet, dass die Eigenschaft vorhanden und nullfähig ist.
• 204 empty bedeutet kein Antwortinhalt.
• CursorPage<T> bedeutet { items: T[], nextCursor: number|string|null }, außer wenn die Zeile ausdrücklich ein page- oder pagination-Objekt nennt.
• Alle nicht gefundenen verschachtelten Ressourcen, auch IDs anderer Workspaces, verwenden 404 { "error": "Workspace resource not found", "code": "RESOURCE_NOT_FOUND" }, sofern eine Funktion keinen spezifischeren Konflikt dokumentiert.

Gemeinsame Anfrageschemas

Workspace- und Standort-Eingaben

WorkspacePatch = {
  name?: string(1..100), email?: email|null, website?: string|null,
  addressLine1?: string|null, addressLine2?: string|null,
  postalCode?: string|null, city?: string|null, state?: string|null,
  countryId?: positive integer
} // at least one property

SiteInput = {
  name: string(1..255), description?: string|null = null,
  addressLine1?: string|null = null, addressLine2?: string|null = null,
  postalCode?: string|null = null, city?: string|null = null, state?: string|null = null,
  countryId: positive integer, timezoneId: positive integer,
  latitude?: number[-90,90]|null = null, longitude?: number[-180,180]|null = null
}

Leistungsmanagement-Eingabe

PowerConfigurationInput = { pools: PowerPoolInput[0..200] }
PowerPoolInput = {
  id?: positive integer|null, name?: string(0..255),
  limit: integer[0,100000000], meterSources?: ExternalMeterInput[0..16],
  children?: (PowerPoolInput | ChargerPoolChild)[0..1000]
}
ChargerPoolChild = { chargepointId: positive integer, priority?: integer[-1000000,1000000] }
ExternalMeterInput = {
  id?: positive integer|null, sourceId?: positive integer|null,
  provider?: "perific", name?: string(0..255), externalId: string(1..80),
  measurementMode?: "available_headroom"|"external_non_ev_load_only"|"total_site_load_including_ev",
  valueMode?: "perific_relative"|"perific_direct"|"perific_meter",
  reserveA?: integer[0,100000], offlineSafeA?: integer[0,100000],
  ttlSeconds?: integer[30,86400], enabled?: boolean
}

Ladegeräte-Eingaben

ChargerCreate = { name: string(1..40), identifier: string(1..40), password?: string(0..40) = "", siteId: positive integer }
ChargerPatch = {
  name?: string(1..40), siteId?: positive integer, invertedRfid?: boolean,
  smartMode?: integer[0,3], automationDisabled?: boolean
} // at least one
ConnectorPatch = {
  connectorFormatId: positive integer, connectorTypeId: positive integer,
  powerTypeId: positive integer, maxVoltage: integer[1,10000],
  maxAmperage: integer[1,10000], maxElectricPower: integer[1,100000000]
}

Berichts-Eingaben

ReportFilters = {
  from?: RFC3339, to?: RFC3339, siteId?: positive integer,
  chargerId?: positive integer, userId?: positive integer,
  anonymous?: true|false|1|0, active?: true|false|1|0
}
ReportScheduleInput = {
  enabled: boolean, recipientEmail: email(max 255; may be empty only when disabled), format: "csv"|"pdf",
  sendDay: integer[1,28], sendTime: UTC "HH:mm"
}

Berichtszeiträume müssen from < to erfüllen und dürfen 90 Tage nicht überschreiten. Ohne Angabe werden die letzten 90 Tage verwendet. userId und anonymous=true schließen sich aus. Geplante Exporte holen eine verpasste UTC-Minute nach und versuchen begrenzt erneut (5/10 Minuten Wartezeit, 30 Minuten Sperrfrist für veraltete Reservierungen, drei Versuche).

Tarif-Eingaben

TariffInput = {
  name: string(1..64),
  exactly one of currencyId: positive integer, currencyCode: 3 letters, currency: 3 letters,
  biddingZoneId?: positive integer|null, tax?: finite number
}
TariffComponentInput = {
  typeId: positive integer, seasonId: positive integer, priority?: finite number,
  price: finite number, validFromMonth?: finite number, validToMonth?: finite number,
  validFromWeekDay?: finite number, validToWeekDay?: finite number,
  validFromHour?: finite number, validToHour?: finite number
}
TariffAssignmentCreateInput = { tariffId: positive integer, connectorId?: nonnegative integer }
TariffAssignmentUpdateInput = { tariffId: positive integer, connectorId: positive integer }

Ladeprofil-Eingaben

ChargingProfileInput = {
  label: string(1..40), locationId: positive integer, stackLevel: nonnegative number,
  purposeId: positive integer, kindId: positive integer,
  recurrencyKindId?: positive integer|null, validFrom?: RFC3339|null,
  validTo?: RFC3339|null, startSchedule?: RFC3339|null,
  rateUnitId: positive integer, minChargingRate?: nonnegative number|null
}
ChargingProfileCreate = ChargingProfileInput & { schedule?: SchedulePeriod[0..256] }
SchedulePeriod = { startPeriod: nonnegative number, limit: nonnegative number, numberOfPhases?: positive integer|null }
ChargingScheduleInput = { rateUnitId: positive integer, periods: SchedulePeriod[1..256] }
ProfileAssignmentInput = { profileId: positive integer, connectorId?: nonnegative integer }

Benutzer-Eingaben

UserCreate = { email: email(max 255), name: string(1..255) }
InvitationInput = {
  email: email, name?: string|null, rfid?: string|null,
  allChargers?: boolean, chargerIds?: unique positive integer[0..500]
} // chargerIds must be non-empty unless allChargers=true
AccessInput = { allChargers?: boolean, chargerIds?: unique positive integer[0..500] }
LimitCreate = { limitTypeId: positive integer, energyValue?: nonnegative integer = 0, timeValue?: nonnegative integer = 0 }
LimitPatch = { limitTypeId?: positive integer, energyValue?: nonnegative integer, timeValue?: nonnegative integer }

Beim Anlegen einer Grenze muss mindestens eines von energyValue oder timeValue größer als null sein. E-Mail-Adressen werden getrimmt und kleingeschrieben. RFID-UIDs werden nur bei Schreibvorgängen angenommen und in Leseantworten maskiert.

Übersicht der Antwort-DTOs

Die Endpunkttabellen zeigen jeden Antwortumschlag oberster Ebene. Dies sind die wichtigsten wiederverwendbaren DTOs darin:

Listen- und Detailrouten liefern Referenzobjekte, damit Aufrufer gültige IDs ermitteln können. Behandeln Sie unbekannte neue Felder vorwärtskompatibel und verzweigen Sie nur anhand dokumentierter stabiler Felder und Fehlercodes.

Workspace-Endpunkte

Standort- und Leistungsmanagement-Endpunkte

Ladegeräte-Endpunkte

Berichts-Endpunkte

Tarif-Endpunkte

TariffAssignment enthält id, chargerId, connectorId, eine unbedenkliche Tarif-/Währungszusammenfassung, createdAt und updatedAt.

Ladeprofil-Endpunkte

ProfileAssignment enthält Zuweisungs-ID, Geräte-/Anschluss-IDs und unbedenkliche Profilzusammenfassung. OCPP-Ergebnisse zeigen stabile Anfrage-/Statusdaten, niemals Zugangsdaten.

Benutzer-, RFID-, Zugriffs-, Grenz- und lokale Benutzerendpunkte

Der Tagless-Systembenutzer ist vor diesen Vorgängen geschützt. Fehler beim Einladungsversand liefern einen unbedenklichen Zustellstatus ohne SMTP-Details; bei emailRetryReady gleich wahr können Aufrufer erneut versuchen.

Binäre Antworten

Zwei Endpunktgruppen liefern bei Erfolg kein JSON:

Fehler binärer Endpunkte bleiben JSON.