generated: '2026-09-05'
method: searched
source: >-
  https://docs.128technology.com/docs/intro_rest_graphql_apis,
  https://docs.128technology.com/docs/config_basics,
  https://docs.128technology.com/docs/intro_rollback,
  https://docs.128technology.com/docs/config_RBAC
scope_note: >-
  Captured from the provider's published documentation. No OpenAPI is available to derive from —
  the SSR serves its Swagger and GraphQL references from the deployed instance itself — so
  anything not stated in the public docs is recorded as unknown rather than inferred.
authentication:
  style: bearer-jwt
  header: 'Authorization: Bearer <token>'
  issuance: POST /api/v1/login with a JSON {username, password} body; the response carries `token`.
  authorization: RBAC — role capabilities (config-read, config-write, provisioning) plus resource groups.
  artifact: authentication/128-technology-authentication.yml
  docs: https://docs.128technology.com/docs/intro_rest_graphql_apis
versioning:
  style: uri-path
  current: v1
  base_path: /api/v1
  artifact: lifecycle/128-technology-lifecycle.yml
  note: >-
    The API version is independent of the product version; the /api/v1 prefix has been stable
    across every SSR release stream from 4.x through 7.2.
content_types:
  request: application/json
  response: application/json
  note: >-
    The documentation states resources are typically represented as JSON or XML; every published
    example uses JSON.
idempotency:
  supported: false
  coverage: none
  header: null
  scope: []
  retention: null
  evidence: >-
    No Idempotency-Key header, request-id de-duplication, or replay-protection mechanism is
    documented anywhere in the SSR documentation, and none appears in any published API example.
  mitigating_mechanism: >-
    Configuration writes are not applied directly. Each user edits a per-user CANDIDATE
    configuration and then commits it; the commit is validated against the current running
    configuration and rejected on conflict. That is a transaction and concurrency-control model,
    not replay protection — a repeated commit of the same candidate is not de-duplicated by a
    key. Recorded here so the mechanism is visible without being mistaken for idempotency.
  docs: https://docs.128technology.com/docs/config_basics
  note: >-
    coverage is `none`, so no Idempotency pointer is emitted in apis.yml.
dry_run_mode:
  supported: true
  mechanisms:
  - name: validate
    description: Validates the candidate configuration without committing it.
    surface: PCLI / configuration mode
  - name: compare config
    description: >-
      Shows the difference between the candidate configuration and the running configuration
      before commit, and after a conflicting commit shows what survived in the candidate.
    surface: PCLI
  - name: create config autogenerated
    description: >-
      Generates and STAGES configuration changes into the candidate configuration so they can be
      validated, inspected and edited before commit.
    surface: PCLI / GUI (Force Configuration Generation)
  docs: https://docs.128technology.com/docs/config_basics
reversibility:
  grade: documented
  grade_note: >-
    Reversal paths are documented and named, but no reversal WINDOW is stated in time units for
    the configuration surface, so this is graded `documented` rather than `verified`. The
    boundaries that ARE stated are recorded per surface below.
  surfaces:
  - surface: configuration change (commit)
    reversal: >-
      Abandon the candidate configuration before commit, or `restore config running` to return to
      the running configuration.
    operation_id: null
    operation_id_note: No OpenAPI is published, so no operationId can be cited.
    window: >-
      Before commit only. Stated boundary rather than a duration: from SSR 5.3 the candidate
      configuration is NOT saved to disk and does not survive a reboot, and the docs recommend
      exporting candidate configurations when making large changes to avoid losing work.
    docs: https://docs.128technology.com/docs/config_basics
  - surface: configuration (full reset)
    reversal: '`restore config factory-default` returns the system to its factory configuration.'
    window: Always available; destructive, not a targeted undo.
    docs: https://docs.128technology.com/docs/config_basics
  - surface: software upgrade
    reversal: '`request system software revert` (progress via `show system software revert`).'
    window: >-
      Stated boundary: rollback to the PREVIOUSLY INSTALLED version is supported. After
      installing or upgrading to SSR 7.1.3 or later, downgrading to an earlier version that
      lacks Configuration Integrity is explicitly NOT supported. Rollback can only be performed
      from the PCLI, not the GUI.
    docs: https://docs.128technology.com/docs/intro_rollback
  - surface: software version selection (reinstall)
    reversal: >-
      `request system software reinstall` performs an image-based reinstall to a version at or
      below the device's current firmware.
    window: Any version listed by `show system software available --skip-version-check`.
    docs: https://docs.128technology.com/docs/intro_rollback
  - surface: users and sessions
    reversal: '`delete user tokens` revokes issued API tokens; `restore users factory-default` resets the user set.'
    window: Immediate; no stated grace period.
    docs: https://docs.128technology.com/docs/cli_reference
pagination:
  style: unknown
  evidence: >-
    Not documented publicly. The pagination behaviour of /api/v1 collection resources is only
    visible in the Swagger reference served from a deployed instance.
concurrency:
  model: candidate-configuration with optimistic merge
  description: >-
    Configuration concurrency was introduced in 5.6. Each user gets a candidate configuration on
    first edit, so multiple administrators can work simultaneously. On commit the updated running
    configuration is compared to the candidate; non-conflicting changes are merged, conflicting
    changes are deleted from the candidate and reported in the error message. `compare-config`
    shows what survived.
  docs: https://docs.128technology.com/docs/config_basics
error_envelope:
  shape: unknown
  problem_json: unknown
  evidence: >-
    No error reference is published. The one error format visible in public docs is the PCLI
    commit failure message, not an HTTP response body.
  note: >-
    errors/ was not written for this provider: there is neither an OpenAPI to derive 4xx/5xx
    responses from nor a published HTTP error reference to search.
rate_limits:
  api_limits: none-documented
  artifact: rate-limits/128-technology-rate-limits.yml
request_tracing:
  header: unknown
  audit_trail: >-
    The SSR emits system audit events for configuration changes and for PKI/certificate API
    operations (expanded in 7.2.0 to cover all success-path certificate operations), and
    `configure authority router router system audit traffic enabled true` turns on traffic
    audit logging. Audit events are a server-side trail, not a client-supplied correlation id.
  docs: https://docs.128technology.com/docs/config_audit_event
field_expansion:
  supported: unknown
  note: >-
    The GraphQL API is the documented mechanism for requesting exactly the fields a client needs;
    it is presented as the alternative to REST for that purpose rather than as a sparse-fieldset
    parameter on the REST surface.
  docs: https://docs.128technology.com/docs/intro_rest_graphql_apis
transport_security:
  tls: required
  note: >-
    Published curl examples pass -k because a factory SSR presents a self-signed webserver
    certificate. Replacing it with a CA-signed certificate is documented.
  docs: https://docs.128technology.com/docs/config_webserver_certs
cross_links:
  authentication: authentication/128-technology-authentication.yml
  lifecycle: lifecycle/128-technology-lifecycle.yml
  conformance: conformance/128-technology-conformance.yml
  rate_limits: rate-limits/128-technology-rate-limits.yml
  cli: cli/128-technology-cli.yml
  events: asyncapi/128-technology-event-surface.yml