Motadata Authentication

specification: API Commons Authentication
specificationVersion: '0.1'
provider: Motadata
providerId: motadata
generated: '2026-08-29'
method: searched
source: >-
  https://docs.motadata.com/observeops-docs/API%20Documentation/observeops-api-documentation,
  https://docs.motadata.com/serviceops-docs/integration-docs/managing-request-using-api,
  https://docs.motadata.com/serviceops-docs/admin-section/automation/integrations/api-integration,
  and the published npm package observeops@2.3.1 (auth reference skill). Probed 2026-08-29.
description: >-
  Motadata runs two products with two different, unrelated authentication models. Both are
  self-hosted, so every credential is issued by the customer's own instance — there is no
  Motadata-operated identity provider, no shared developer portal, and no central key issuance.
  No /.well-known/openid-configuration or /.well-known/oauth-authorization-server is served on
  any Motadata host (all 404 or SPA shell; see well-known/motadata-well-known.yml).
apis:
  - api: motadata:observeops
    name: Motadata ObserveOps (AIOps)
    docs: https://docs.motadata.com/observeops-docs/API%20Documentation/observeops-api-documentation
    base: https://{observeops-host}/api/v1
    securitySchemes:
      - key: BearerAuth
        type: http
        scheme: bearer
        bearerFormat: JWT
        in: header
        name: Authorization
        description: >-
          Personal Access Token (PAT). Generated by the user from the Motadata ObserveOps UI;
          Motadata does not issue it. Sent as `Authorization: Bearer <PAT>`.
        note: >-
          A PAT cannot open the Vert.x EventBus websocket. Live streaming, alert actions and
          raw EventBus calls require a username/password session login instead — a real
          capability split between the two credential types, documented in Motadata's own
          observeops-eventbus agent skill.
      - key: CookieAuth
        type: apiKey
        in: cookie
        name: cookie
        description: >-
          A static `client.id=...` cookie value documented in the ObserveOps API reference as
          "static and does not change over time". The literal value published in the docs is
          deliberately not reproduced here.
      - key: SessionLogin
        type: http
        scheme: basic
        description: >-
          Username/password login producing a session the CLI refreshes automatically
          (`observeops auth login`). Required for the websocket/EventBus surface.
  - api: motadata:serviceops
    name: Motadata ServiceOps (ITSM)
    docs: https://docs.motadata.com/serviceops-docs/integration-docs/managing-request-using-api
    base: https://{serviceops-host}/api
    securitySchemes:
      - key: OAuth2Password
        type: oauth2
        flow: password
        tokenUrl: https://{serviceops-host}/api/oauth/token
        description: >-
          OAuth 2.0 resource-owner-password-credentials grant. The registered integration's
          ClientID and ClientSecret are joined with a colon, Base64 encoded and sent as
          `Authorization: Basic <base64>`; the end user's ServiceOps username and password plus
          `grant_type=password` go in a multipart/form-data body. The response carries
          access_token, token_type "Bearer", expires_in and scope.
        request_headers:
          - 'Authorization: Basic {base64(ClientID:ClientSecret)}'
          - 'content-type: multipart/form-data'
        note: >-
          The documented example uses http:// against {{server-url}}. Transport security is the
          customer's deployment choice, not a Motadata-enforced default.
      - key: ApiKey
        type: apiKey
        in: header
        name: Authorization
        scheme_prefix: Apikey
        description: >-
          V1 API key created at Admin > Automation > Integrations > API Integration, bound to a
          named integration and a specific ServiceOps user. Sent as `Authorization: Apikey <key>`
          — note the prefix is the literal word "Apikey", not "Bearer".
        note: >-
          Motadata's own documentation renders a full example key in this page. Key rotation and
          expiry are not documented.
      - key: WebhookEndpointAuth
        type: apiKey
        in: header
        name: Authorization
        description: >-
          Inbound-only. ServiceOps webhook endpoints issue an Endpoint URL plus an Authorization
          Key (header) or an auth query parameter, for external systems posting INTO ServiceOps.
        docs: https://docs.motadata.com/serviceops-docs/admin-section/automation/integrations/webhook-endpoints
findings:
  - >-
    No OAuth scope model on ObserveOps: authorization is per-user permissions carried by the
    PAT/session, not scopes on a token.
  - >-
    ServiceOps issues exactly one scope value, `other-api-scope`, on every token — a scope field
    that exists structurally but does not partition access.
  - >-
    Both products are on-premise. There is no public authorization server to probe, which is why
    every /.well-known/oauth-* and openid-configuration path 404s.
maintainers:
  - FN: Kin Lane
    email: kin@apievangelist.com