Żądania i odpowiedzi punktów końcowych API administracyjnego obszaru roboczego

To dokumentacja żądań i odpowiedzi dla każdego punktu końcowego /v2/admin. Uwierzytelnianie, idempotencja, limity częstotliwości, tworzenie tokenów i znaczenie zakresów uprawnień opisano w API administracyjnym obszaru roboczego. Typy pól wielokrotnego użytku i przykłady są w sekcji Schematy i przykłady. Każdy wiersz punktu końcowego czytaj razem z Kontraktem odpowiedzi i błędów, który wymienia wszystkie możliwe wspólne i specyficzne treści odpowiedzi niepowodzenia.

Wspólny kontrakt

Każda ścieżka zaczyna się adresem źródłowym wdrożonej usługi app-api. Obszar roboczy jest wyznaczany wyłącznie na podstawie uwierzytelnionego tokena; klienci nie mogą wysyłać cpoId. Wszystkie udokumentowane wartości :...Id w ścieżkach zasobów są dodatnimi dziesiętnymi liczbami całkowitymi. Każde żądanie wymaga dokładnie jednego:

Authorization: Bearer <workspace-access-token>

Żądania pokazane z treścią JSON wymagają Content-Type: application/json. Wszystkie operacje zmieniające dane wymagają Idempotency-Key (POST, PUT, PATCH i DELETE), w tym POST /v2/admin/reports/send; o ile wiersz nie stanowi inaczej, typ zawartości pomyślnej odpowiedzi to application/json, daty JSON są ciągami RFC 3339, a liczby są liczbami JSON.

Każde żądanie może zawierać X-Request-Id i X-Error-Format: envelope; zobacz Kontrakt odpowiedzi i błędów. Te nagłówki nie zmieniają schematów pomyślnych odpowiedzi.

Oznaczenia używane poniżej:

• none oznacza brak treści żądania. DELETE, dla którego udokumentowano treść JSON, nadal jej wymaga.
• ? oznacza opcjonalną właściwość lub parametr zapytania.
• T | null oznacza, że właściwość występuje i może mieć wartość null.
• 204 empty oznacza brak treści odpowiedzi.
• CursorPage<T> oznacza { items: T[], nextCursor: number|string|null }, chyba że wiersz jawnie wskazuje obiekt page lub pagination.
• Wszystkie przypadki braku zagnieżdżonego zasobu, także identyfikatory z innego obszaru roboczego, używają 404 { "error": "Workspace resource not found", "code": "RESOURCE_NOT_FOUND" }, chyba że dokumentacja funkcji wskazuje bardziej konkretny konflikt.

Wspólne schematy żądań

Dane wejściowe obszaru roboczego i lokalizacji

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
}

Dane wejściowe zarządzania mocą

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
}

Dane wejściowe ładowarek

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]
}

Dane wejściowe raportów

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"
}

Zakresy raportów muszą spełniać from < to i nie mogą przekraczać 90 dni. Po pominięciu używane są ostatnie 90 dni. userId i anonymous=true wzajemnie się wykluczają. Zaplanowane eksporty nadrabiają pominiętą minutę UTC i używają ograniczonych ponowień (odstęp 5/10 minut, 30-minutowa rezerwacja przeterminowanego zadania, trzy próby).

Dane wejściowe taryf

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 }

Dane wejściowe profili ładowania

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 }

Dane wejściowe użytkowników

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 }

Podczas tworzenia limitu co najmniej jedno z pól energyValue lub timeValue musi być większe od zera. Z adresów e-mail usuwane są skrajne spacje, a litery zmieniane na małe. UID RFID są przyjmowane tylko przy zapisie i maskowane w odpowiedziach odczytu.

Podsumowanie DTO odpowiedzi

Tabele punktów końcowych pokazują każde opakowanie odpowiedzi najwyższego poziomu. To główne wielokrotnie używane DTO wewnątrz tych opakowań:

Obiekty słownikowe są zwracane przez ścieżki list i szczegółów, aby wywołujący mogli odkrywać prawidłowe identyfikatory. Nieznane dodane pola traktuj jako rozszerzenia zgodne z przyszłymi wersjami, a decyzje opieraj wyłącznie na udokumentowanych stabilnych polach i kodach błędów.

Punkty końcowe obszaru roboczego

Punkty końcowe lokalizacji i zarządzania mocą

Punkty końcowe ładowarek

Punkty końcowe raportów

Punkty końcowe taryf

TariffAssignment zawiera id, chargerId, connectorId, bezpieczne podsumowanie taryfy/waluty, createdAt i updatedAt.

Punkty końcowe profili ładowania

ProfileAssignment zawiera identyfikator przypisania, identyfikatory ładowarki/złącza i bezpieczne podsumowanie profilu. Obiekty wyników OCPP ujawniają stabilne informacje żądania/statusu, nigdy dane uwierzytelniające.

Punkty końcowe użytkowników, RFID, dostępu, limitów i użytkowników lokalnych

Użytkownik systemowy Tagless jest chroniony przed tymi operacjami. Niepowodzenia wysyłki zaproszenia e-mailem zwracają bezpieczny stan dostarczenia bez ujawniania szczegółów SMTP; wywołujący mogą ponowić próbę, gdy emailRetryReady ma wartość true.

Odpowiedzi binarne

Dwie grupy punktów końcowych nie zwracają JSON przy powodzeniu:

Błędy binarnych punktów końcowych nadal mają format JSON.