RELEX Solutions Events API

openapi: 3.2.0
info:
  contact:
    email: support@relexsolutions.com
    name: RELEX Solutions
  description: "# Introduction to the Monitoring API \n\nThe RELEX Monitoring API provides a way to access monitoring data for RELEX services. \nThe API allows customers to retrieve information about events that have occurred in \ntheir environments, such as file processing events and job execution events. \n\n## Current features\n\n* File and job execution events related to RELEX supply chain planning services.\n* Prometheus-compatible metrics endpoint for data ingestion golden signals.\n\n## Monitoring API use cases \n\nRELEX customers can use the Monitoring API to:\n\n* Monitor the progress of file processing events. Since the set of uploaded files is known,\n  RELEX users can poll the Monitoring API to check the status of each file. If a file seems \n  to be stuck in processing or has failed validation, the user can take action to correct the issue.\n* Monitor the progress of job execution events. RELEX users can poll the Monitoring API to check \n  the status of important jobs, such as supply chain planning calculation runs. A job failing to complete by a\n  certain time can indicate a problem with the data or the RELEX service.\n* Query data ingestion metrics to monitor throughput and latency of data flowing\n  into RELEX. Customers can use these metrics to build dashboards and alerts in their own\n  observability platforms via Prometheus-compatible scraping or federation.\n\n## Event type overview\n\n### File events and statuses\n\n*See the [Get File Events endpoint](#operation/get-file-events) for example file event payload.*\n\nFile events are grouped by the file name originally used when uploading the file to RELEX. \nThe file events endpoint returns a list of file names along with the current status of \nthe data contained in each file. The status of a file can be one of the following:\n\n| Status | Description |\n|--------|-------------|\n| Received | The file has been received by RELEX, but no further processing has yet happened. |\n| Processing | The data contained in the file is being validated and transferred via intermediate storage to RELEX supply chain planning. |\n| Processed | The data is fully validated and ready to be used in supply chain planning calculations. |\n| Exported | A customer-facing file has been created by RELEX, but it has not yet been delivered to customer-facing storage. |\n| Delivering | A customer-facing file is currently being delivered to customer-facing storage. |\n| Delivered | A customer-facing file has been delivered to customer-facing storage. |\n| Warning | A non-critical issue was encountered during processing of the file. Usually caused by some rows being skipped during file validation. |\n| Error | A critical error occurred during processing of the file. |\n\nAlong with the status, the file events endpoint returns a list of events that have occurred.\n\n| Event | Description |\n|-------|-------------|\n| File received | The file has been received in an upload location by RELEX. |\n| File preparation started | The file is being read in and validated by the data integration application known as RELEX Connect. |\n| File preparation completed | The file has been fully validated by RELEX Connect and the data is now uploaded to intermediate storage for use in supply chain planning. |\n| File import started | The data is now being read from intermediate storage to RELEX Plan, the core RELEX supply chain planning application. |\n| File import completed | The data has been fully read and is ready for use in supply chain planning calculations. |\n| File is ready for processing | The data is ready for pricing and promotion strategy optimization. |\n| Export file created | A customer-facing export file has been created by RELEX. |\n| Export file ready for preparation | The export file is being prepared for delivery to customer-facing storage. |\n| Export file uploaded to customer-facing storage | The export file has been uploaded to customer-facing storage and is available for download. |\n\n#### Integration direction\n\nThe API provides information about the direction of data integration. Two types of integration are supported: inbound and outbound.\n* Inbound integration is used to upload data to RELEX.\n* Outbound integration is used to download data from RELEX.\n\nThe integration direction is indicated in the file event payload via the direction field. It can also be specified as an optional direction query parameter in the file event endpoint.\nAdditionally:\n* For inbound integrations, the file event payload includes the input_url field, which defines the full path of the file on the file server.\n* For outbound integrations, the corresponding field is output_url.\n\nPossible values for the 'direction' field are:\n| Direction | Description | File path field name |\n|-----------|-------------|-------------|\n| inbound   | Data is being uploaded to RELEX. | input_url | \n| outbound  | Data is being downloaded from RELEX. | output_url |\n\n#### File rows\n\n> ⚠️ Functionality is available from Plan 10.6 and higher.\n\nEvents with 'File preparation started', 'File preparation completed', and 'File import completed' statuses also include information about the number of total and skipped rows in the file. \nThis information is provided in 'file_rows' object. The 'file_rows' object contains the following fields:\n\n| Field | Description |\n|-------|-------------|\n| total | Total number of data rows present in the uploaded file. |\n| skipped | Number of rows skipped while processing the uploaded file |\n\nFor some events, the API provides information on the reasons for skipping rows, in which case the event will also include a 'warnings' object.  \nThe overall status of the file will be 'Warning' if any rows were skipped during processing, unless there were also critical errors.\n\nExample:\n```json \n{\n  \"file\": \"transactions_20251204_110001.csv\",\n  \"input_url\": \"https://example-storage.blob.core.windows.net/input\",\n  \"status\": \"Warning\",\n  \"direction\": \"inbound\",\n  \"file_size\": 694713,\n  \"timestamp\": \"2025-12-04T14:12:10Z\",\n  \"events\": [\n    {\n      \"title\": \"File received\",\n      \"timestamp\": \"2025-12-04T11:36:01Z\"\n    },\n    {\n      \"title\": \"File preparation started\",\n      \"timestamp\": \"2025-12-04T14:11:48Z\",\n      \"file_rows\": {\n        \"total\": 5973,\n        \"skipped\": 1339\n      },\n      \"warnings\": [\n        {\n          \"details\": \"Null value in non-null column relex_transaction_type\",\n          \"count\": 1326,\n          \"example_rows\": [\n            \"2025-12-03,LOC01,LOC02,,-6.0,CS,-6.0,CS,REF001,Invoice,TYPE1,CAT1,ORD001,ID001,SO\",\n            \"2025-12-03,LOC01,LOC02,,-1.0,CS,-1.0,CS,REF002,Invoice,TYPE1,CAT1,ORD002,ID002,SO\",\n            \"2025-12-03,LOC01,LOC02,,-35.0,CS,-35.0,CS,REF003,Invoice,TYPE1,CAT1,ORD003,ID003,SO\",\n            \"2025-12-03,LOC01,LOC02,,-8.0,CS,-8.0,CS,REF004,Invoice,TYPE1,CAT1,ORD004,ID004,SO\",\n            \"2025-12-03,LOC01,LOC02,,-36.0,CS,-36.0,CS,REF005,Invoice,TYPE1,CAT1,ORD005,ID005,SO\"\n          ]\n        },\n        {\n          \"details\": \"Null value in non-null column primary_qty\",\n          \"count\": 13,\n          \"example_rows\": [\n            \"2025-12-03,LOC03,SKU01,DELIVERY,,LB,40.0,CS,REF006,IR Description,TYPE2,CAT2,ORD006,ID006,OT\",\n            \"2025-12-03,LOC03,SKU02,DELIVERY,,LB,60.0,CS,REF007,IR Description,TYPE2,CAT2,ORD007,ID007,OT\",\n            \"2025-12-03,LOC03,SKU03,DELIVERY,,LB,60.0,CS,REF008,IR Description,TYPE2,CAT2,ORD008,ID008,OT\",\n            \"2025-12-03,LOC03,SKU04,DELIVERY,,LB,55.0,CS,REF009,IR Description,TYPE2,CAT2,ORD009,ID009,OT\",\n            \"2025-12-03,LOC01,SKU05,DELIVERY,,LB,192.0,CS,REF010,IR Description,TYPE2,CAT2,ORD010,ID010,OP\"\n          ]\n        }\n      ]\n    },\n    {\n      \"title\": \"File preparation completed\",\n      \"timestamp\": \"2025-12-04T14:12:10Z\",\n      \"file_rows\": {\n        \"total\": 4634,\n        \"skipped\": 0\n      }\n    }\n  ]\n},\n```\n\nThe following table lists the most common warning messages:\n\n| Warning Details | Reason |\n|-------|-------------|\n| Missing required non-null fields, fields=”*comma-separated list of fields*” | The input file specification contains fields marked as 'Not null', but the provided file is missing these fields. |\n| Could not parse value of type \"*type-name*\" | The input file specification defines a field of a specific type, but the provided file contains a value that does not match the specified type. |\n| Number of columns on row does not match the header or linebreaks are inconsistent | The number of fields in the provided file does not match the input file specification, or inconsistent linebreaking characters are used in the data. |\n\n#### File size\n\n> ⚠️ Functionality is available for SFTP file uploads\n\nShows the size of the file in bytes. The file size is included in the `file_size` field of the file event object.\n\n#### Errors\n\nIf a critical error occurs during file processing, the endpoint will return a list of errors and the overall status of the\nfile is \"Error\". Each error consists of a title that describes at what stage the error occurred and a details field \nthat provides more information about the error.\n\nExample:\n\n```json \n{\n  \"file\": \"Locations_2025-01-23.csv\",\n  \"status\": \"Error\",\n  \"timestamp\": \"2025-01-23T07:38:22Z\",\n  \"file_size\": 15,\n  \"events\": [\n    {\n      \"title\": \"File preparation started\",\n      \"timestamp\": \"2025-01-23T07:38:16Z\"\n    }\n  ],\n  \"errors\": [\n    {\n      \"title\": \"File preparation started\",\n      \"details\": \"The file you are looking for may have been moved or deleted\"\n    }\n  ]\n```\n\n### Job events\n\n*See the [Get Job Events endpoint](#operation/get-job-events) for example job event payload.*\n\nThe RELEX Monitoring API provides access to events linked to RELEX Plan job executions.\nBy querying the job events endpoint, RELEX users can find out about the current state of \nscheduled jobs in RELEX Plan and whether or not they have completed successfully. \n\nJobs can have the following statuses:\n\n| Status | Description |\n|--------|-------------|\n| Running | The job is in progress. |\n| Canceled | The job was canceled when the Cancel button was selected. The job is also marked as Canceled if the continue criteria set in WaitFor is not met and WaitFor is set to not continue the execution of the job. |\n| Completed | The job has completed successfully. |\n| Error | The job has failed or has been aborted by the system (for example, due to a system restart). |\n| Queued | The job is lined up and waiting to be processed. There are more jobs started than can be executed simultaneously. You can configure the number, and the default is 5 jobs. The job remains in the Queued status until earlier jobs have completed. |\n| Warning | The job has completed, but some of the child runs executed within the job have failed with an error. |\n| Pending | The job is awaiting initiation. |\n| Delayed | The job start has been postponed. |\n\nJobs can be filtered by a number of fields, including:\n* job name (`job_name`) - the request will return jobs whose names contain the specified string\n* job parent name (`job_parent_name`) - will return jobs whose parent job name contain the specified string\n\n# Getting started\n\nTo start using the Monitoring API, ensure you have received your Client ID and Client Secret.  \n* Proceed to the [Authentication](#section/Authentication-and-security) section of this documentation, which covers how to get a valid token.  \n* Once you have a token, you can start using the API. Each request to any of the API endpoints should contain the token as described in [Accessing the Monitoring API with tokens](#section/Authentication-and-security/Accessing-the-Monitoring-API-with-tokens).  \n* All the available endpoints with their parameters are listed [further below](#operation/get-environments) in this document.  \n\nA simple client code snippet in Python for reference is maintained in this repository:  \nhttps://github.com/relex/monitoring-api-demo\n\n# API specification\n\nThis section covers the data resources and technical details of the RELEX Monitoring API.\n\n> ⚠️ **All API requests must be made over HTTPS**\n>\n> Calls made over plain HTTP will fail and return an HTTP Status Code 400 Bad Request.\n\n## API glossary\n\n* A **resource** is an object with a type, associated data, relationships to other resources, and a set of methods that operate on it. In practice, *the resource* most often maps to a corresponding database table, but not always.\n\n## JSON format\n\nThe RELEX Monitoring API uses JSON as the format for data serialization. \nThe JSON payload of the API has a root-level object that contains a \nmeta-object and data array element.\n\nAll resources have a defined schema, and the details of each resource \ncan be examined in the resource specifications in this document.\n\n## Dates and times\n\nDate and time can be represented with a single field type expected to follow the [ISO 8601](https://www.iso.org/iso-8601-date-and-time-format.html) standard.\n\n* **date-time**: With date and time combined. Format: yyyy-MM-ddThh:mm:ssZ, for example `2023-12-05T13:45:10Z`.\n\n## Server URLs based on region\n\nThe base URL for API requests depends on the region where the client is located. \nThe following URLs should be used depending on the region:\n\n| Region | Base URL |\n|--------|----------|\n| EU     | `https://eu.monitor.relexsolutions.com` |\n| US     | `https://us.monitor.relexsolutions.com` |\n\nEnsure that all API requests use the appropriate base URL for your region.\nFor example, an API request for a customer in the EU would be:\n\n  ```\n  GET https://eu.monitor.relexsolutions.com/api/v1/{customer_id}/events/file?env=test\n  ```\n\nFor more examples, see the operations dropdown menu on the right side of the page.\n\n## Request processing\n\nMonitoring API resources respond to requests synchronously.\n\n* Authentication is done synchronously and immediately when the client sends a request.\n* The client receives a response with a 200 HTTP status code and the requested data if \n  RELEX is able to accept the request successfully.\n* If a non-2xx status code is returned, it indicates that RELEX's synchronous part has \n  failed (500 status code) or the client's request is incorrect (4xx status code).\n\n## Error responses\n\nThe RELEX Monitoring API uses standard HTTP response codes to indicate the various \nfailures an API request can return. Codes in the 4xx range indicate an error on \nthe client side, for example, the resource name was incorrect. Codes in the 5xx range \nindicate an error within RELEX services.\n\nTo convey details about errors to clients in JSON responses, the RELEX Monitoring API \nuses the [RFC 7807](https://tools.ietf.org/html/rfc7807) standard.\n\n| Error code | Description |\n|------------|-------------|\n| 400 Bad Request | The request was unacceptable, for example, due to a missing parameter |\n| 401 Unauthorized | The client must log in. This often means \"Unauthenticated\" |\n| 403 Forbidden | Authentication/authorization failed. The bearer token provided might be invalid, expired, or revoked, or the `customer_id` path parameter is incorrect |\n| 404 Not Found | Resource was not found |\n| 405 Method not allowed | The request method is not supported by the target resource |\n| 429 Too Many Requests | Request limit has been reached |\n| 500 Internal Server Error | Generic server error indicating an unexpected problem. A client may retry |\n\n## Quotas and limits\n\nThe RELEX Monitoring API imposes limits on incoming web requests to ensure performance, \nreliability, and efficiency. The API sets the following limits:\n\n### Overall limit \n\nOverall limit is 100,000 requests per 5 minutes from a single customer IP address. \nApplies to all endpoints and requests to the API.\n\n### /api/v{N}/{customer_id}/events/job endpoint limits\n\nThe limit for the `/api/v{N}/{customer_id}/events/job` endpoint is 100 requests per minute from \na single customer IP address.\n\n### /api/v{N}/{customer_id}/events/file endpoint limits\n\nThe limit for the `/api/v{N}/{customer_id}/events/file` endpoint is 100 requests per minute from \na single customer IP address.\n\n### /api/v{N}/health endpoint limits\n\nThe limit for the `/api/v{N}/health` endpoint is 12 requests per minute from a single customer IP address.\n\nIf the limits are exceeded, an HTTP status code 429 is returned.\n\n### Exceeding limits\n\nℹ️ API limits are subject to change and appropriate values are determined during the implementation project.\n\nThe RELEX Monitoring API imposes no limits on return payloads. The payload size can be arbitrarily large.\n\n# Authentication and security\n\nThis section describes the authentication methods and security-related \nrequirements for the Monitoring API.\n\n## Authentication\n\nThe Monitoring API utilizes OAuth 2.0 and [OpenID Connect](http://openid.net/connect/) (OIDC) \nfor authentication and authorization. OIDC is an authentication layer on top of \n[OAuth 2.0](https://oauth.net/2/) and [JSON Web Tokens](https://tools.ietf.org/html/rfc7519) (JWT).\n\nThe API is secured via a JWT access token, which must be present in each request.\nThe JWT is fetched from a [token endpoint](https://tools.ietf.org/html/rfc6749#section-3.2) \nof RELEX Identity (an Identity Provider) using a Client ID and a Client Secret.\n\n<!-- ReDoc-Inject: <security-definitions> -->\n\n## Authorization steps\n\nThe Monitoring API implements authorization using the Client Credentials Grant.\nIt is an authorization flow defined in the [OAuth 2.0 specification](https://tools.ietf.org/html/rfc6749#section-4.4),\nwhich is typically used for allowing access to resources in an automated context; \nthat is, in a context with no human input.\n\nThe general steps involved are as follows:\n\n1. **Pre-requisites**: Obtain the information the client needs to request an access token, and configure it in the client application. This is a one-time step.\n2. **Authorization**: The client application requests an Access Token from RELEX Identity using the information provided in step 1.\n3. **Access**: The client includes the provided Access Token in its requests, which allows it to access the Monitoring API endpoints.\n\n### Pre-requisites\n\nTo authenticate with RELEX Identity, the client needs:\n\n* A Client ID\n* A Client Secret\n* A RELEX Identity token endpoint URL\n\nThese are provided by RELEX during the implementation process.\nAfter this information has been provided, it needs to be configured into\nthe client application according to the application's specific needs.\n\n## Authorization: Acquiring an Access Token from RELEX Identity\n\n### Token endpoint based on region\n\nThe token endpoint URL for obtaining the JWT access token depends on the region. The following URLs should be used depending on the region where the client operates:\n\n| Region | Token endpoint URL |\n|--------|--------------------|\n| EU     | `https://identity.prod-eu.prod.cc.relexsolutions.com/monitoring_api_prod/connect/token` |\n| US     | `https://identity.prod-us.prod.cc.relexsolutions.com/monitoring_api_prod/connect/token` |\n\n1. The client sends a POST request to the provided RELEX Identity token endpoint\n  * Content type needs to be set to `application/x-www-form-urlencoded`\n  * The Client ID, Client Secret, and `client_credentials` grant type must be included in the POST body as URL-encoded key-value pairs.\n  \n  An example body:\n  \n  ```\n  client_id=my_client&client_secret=ZWFzdGVyZWdnCg&grant_type=client_credentials\n  ```\n2. RELEX Identity authenticates the client.\n3. If authentication is successful, RELEX Identity authorizes the client by responding with a JSON object that contains:\n  * `\"access_token\"`: the JWT token that needs to be used for accessing the Monitoring API\n  * `\"expires_in\"`: the access token's time to live in seconds\n  * `\"token_type\"`: information on how the token needs to be used, in this case, always set to \"Bearer\".\n  * `\"scope\"`: The scope that the token grants access to.\n  \n## Accessing the Monitoring API with tokens\n\nWhenever the client accesses any Monitoring API endpoint, the client must provide the following:\n\n* A valid access token in an `Authorization` -header, preceded by `Bearer`. An example header is `Authorization: Bearer eyJ[...]jw`.\n\n## Access token expiry\n\nWhen an Access Token expires, Monitoring API calls respond with `401 Unauthorized`\nThe client application has two options to keep it authenticated:\n\n* The client may handle 401 responses and react by initiating a new Client Credentials grant, as described in the \"Authorization steps\" section.\n* The client may monitor the token's expiry interval. When the grant is about to expire, the client fetches a new token.\n\n**Note:** the Client Credentials grant type is not compatible with a construct such as refresh tokens, \nas mentioned in the protocol [specification](https://tools.ietf.org/html/rfc6749#section-4.4.3).\n\n## An example authorization flow\n\n### Client configuration\n\nIn our example flow, we have the following client-specific information:\n\n* Client ID: `customer_id-monitoring-api`\n* Client Secret: `ZWFzdGVyZWdnCg`\n* Token endpoint URL(assuming that client is based in EU): `https://identity.prod-eu.prod.cc.relexsolutions.com/monitoring_api_prod/connect/token`\n\nFor demonstration purposes, we'll use `curl` as a client.\n\n### Authorization\n\n1. We POST our authorization request to the token endpoint.\n\n```bash\n% curl -vd \"grant_type=client_credentials&client_id=customer_id-monitoring-api&client_secret=ZWFzdGVyZWdnCg\" https://identity.prod-eu.prod.cc.relexsolutions.com/monitoring_api_prod/connect/token\n[...]\n> POST /monitoring_api_prod/connect/token HTTP/1.1\n> Host: identity.prod-eu.prod.cc.relexsolutions.com\n> Accept: */*\n> Content-Type: application/x-www-form-urlencoded\n[...]\n< HTTP/1.1 200 OK\n< Content-Type: application/json; charset=UTF-8\n[...]\n```\n\nAs a response body, we get the following:\n\n```bash\n{\"access_token\":\"eyJ[...]jw\",\"expires_in\":3600,\"token_type\":\"Bearer\",\"scope\":\"example-scope\"}\n```\n\n2. We extract the access token from the response field of the `\"access_token\"`.\n3. We use this token to access an API resource. In our case `/api/v1/customer_id/events/file`:\n\n```bash\n% curl -H \"Authorization: Bearer eyJ[...]jw\" https://eu.monitor.relexsolutions.com/api/v1/customer_id/events/file\n> GET /api/v1/customer_id/events/file HTTP/1.1\n> Host: eu.monitor.relexsolutions.com\n> Authorization: Bearer eyJ[...]jw\n[...]\n< HTTP/1.1 200 OK\n[...]\n```\n## IP allowlist\n\nAs an additional layer of security, the Monitoring API can be configured to allow requests from only certain \nIP addresses or ranges. The recommendation is to always have an IP allowlist in place.\nThe API does not support an explicit blocklist.\n"
  title: Monitoring Events API
  version: 1.24.0
  x-logo:
    url: /img/monitoring.png
    backgroundColor: '#FFFFFF'
    altText: RELEX Solutions logo
servers:
- url: https://eu.monitor.relexsolutions.com
  description: For business requests from EU-based customers
- url: https://us.monitor.relexsolutions.com
  description: For business requests from US-based customers
tags:
- name: Events
  description: Endpoints for fetching files and jobs event data.
paths:
  /api/v{N}/{customer_id}/events/file:
    get:
      tags:
      - Events
      description: Returns file events owned by the requesting customer. Supports filtering via query parameters. The response includes one entry per file where at least one event occurred within the requested timeframe.
      operationId: get-file-events
      summary: Get file events
      parameters:
      - description: API version, MAJOR format
        in: path
        name: N
        required: true
        example: 1
        schema:
          type: integer
          enum:
          - 1
      - description: ID of the customer who the events belong to
        in: path
        name: customer_id
        required: true
        example: example-customer
        schema:
          type: string
      - description: Customer environment to fetch the events from
        in: query
        name: env
        required: true
        example: dev
        schema:
          type: string
          minLength: 1
          maxLength: 20
      - description: File name filter; returns files whose names contain this string
        in: query
        name: file_name
        required: false
        example: somefile.json
        schema:
          type: string
          minLength: 1
          maxLength: 512
      - description: Start timestamp (inclusive). Must not be later than `end_timestamp`.
        in: query
        name: start_timestamp
        required: false
        example: '2026-01-01T05:10:06+00:00'
        schema:
          type: string
          format: date-time
      - description: End timestamp (exclusive). Must not be earlier than `start_timestamp`.
        in: query
        name: end_timestamp
        required: false
        example: '2026-03-01T20:10:06+00:00'
        schema:
          type: string
          format: date-time
      - description: Integration direction (case-insensitive)
        in: query
        name: direction
        required: false
        example: inbound
        schema:
          type: string
          enum:
          - inbound
          - outbound
      - description: The ID of RELEX Plan job to filter file events by
        in: query
        name: job_id
        required: false
        example: '12345'
        schema:
          type: string
          pattern: ^[0-9]+$
      - description: Current event flow status (case-insensitive); supports exploded array syntax, eg. `status=error&status=warning`
        in: query
        name: status
        required: false
        example: warning
        style: form
        explode: true
        schema:
          type: array
          items:
            type: string
            enum:
            - Error
            - Warning
            - Exported
            - Delivering
            - Delivered
            - Received
            - Processing
            - Processed
      - description: Page number, 1-based
        in: query
        name: page
        example: 1
        schema:
          type: integer
          default: 1
          minimum: 1
          maximum: 9223372036854776000
      - description: Number of file event flows per page
        in: query
        name: per_page
        example: 50
        schema:
          type: integer
          default: 50
          minimum: 1
          maximum: 1000
      responses:
        '200':
          description: Data was found and returned
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/FileEventResult'
        '400':
          description: Client error, please check the request parameters
          content:
            application/problem+json:
              schema:
                $ref: '#/components/schemas/RequestError'
        '401':
          description: No authentication was provided
        '403':
          description: Authentication error
        '404':
          description: Requested path was not found
        '429':
          description: Too Many Requests
        '500':
          description: Internal server error
          content:
            application/problem+json:
              schema:
                $ref: '#/components/schemas/RequestError'
      security:
      - oauth2: []
  /api/v{N}/{customer_id}/events/job:
    get:
      tags:
      - Events
      description: Returns job events executed on customer environment. Supports filtering via query parameters.
      operationId: get-job-events
      summary: Get job events
      parameters:
      - description: API version, MAJOR format
        in: path
        name: N
        required: true
        example: 1
        schema:
          type: integer
          enum:
          - 1
      - description: ID of the customer who the events belong to
        in: path
        name: customer_id
        required: true
        example: example-customer
        schema:
          type: string
      - description: Customer environment to fetch the events from
        name: env
        in: query
        required: true
        example: dev
        schema:
          type: string
          minLength: 1
          maxLength: 20
      - description: Uniquely identifies a specific execution of the job
        in: query
        name: job_id
        required: false
        example: 1234
        schema:
          type: integer
          minimum: 1
          maximum: 9223372036854776000
      - description: The job_id of the parent job
        in: query
        name: job_parent_id
        required: false
        example: 1234
        schema:
          type: integer
          minimum: 1
          maximum: 9223372036854776000
      - description: The ID of the process which created the scheduled job, which doesn't change between job executions
        in: query
        name: run_id
        required: false
        example: 00000000-0000-0000-0000-000000000000
        schema:
          type: string
          format: uuid
      - description: The run_id of the parent job
        in: query
        name: run_parent_id
        required: false
        example: 00000000-0000-0000-0000-000000000000
        schema:
          type: string
          format: uuid
      - description: Name of the scheduled job. The API returns all jobs whose names include the specified string.
        in: query
        name: job_name
        required: false
        example: Scheduled job
        schema:
          type: string
          minLength: 1
          maxLength: 512
      - description: Name of the parent job. The API returns all jobs whose parent names include the specified string.
        in: query
        name: job_parent_name
        required: false
        example: Cleanup run
        schema:
          type: string
          minLength: 1
          maxLength: 512
      - description: Current job status (case-insensitive); supports exploded array syntax, eg. `status=error&status=warning`
        in: query
        name: status
        required: false
        example: warning
        style: form
        explode: true
        schema:
          type: array
          items:
            type: string
            enum:
            - Pending
            - Delayed
            - Queued
            - Running
            - Canceled
            - Completed
            - Warning
            - Error
      - description: Start timestamp (inclusive). Must not be later than `end_timestamp`.
        in: query
        name: start_timestamp
        required: false
        example: '2026-01-01T05:10:06+00:00'
        schema:
          type: string
          format: date-time
      - description: End timestamp (exclusive). Must not be earlier than `start_timestamp`.
        in: query
        name: end_timestamp
        required: false
        example: '2026-03-01T20:10:06+00:00'
        schema:
          type: string
          format: date-time
      - description: Page number, 1-based
        in: query
        name: page
        example: 1
        schema:
          type: integer
          default: 1
          minimum: 1
          maximum: 9223372036854776000
      - description: Number of job execution results per page
        in: query
        name: per_page
        example: 50
        schema:
          type: integer
          default: 50
          minimum: 1
          maximum: 1000
      responses:
        '200':
          description: Data was found and returned
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/JobEventResult'
        '400':
          description: Client error, please check the request parameters
          content:
            application/problem+json:
              schema:
                $ref: '#/components/schemas/RequestError'
        '401':
          description: No authentication was provided
        '403':
          description: Authentication error, make sure the customer_id path parameter and the customer in 'client_id' token claim match each other
        '404':
          description: Requested path was not found
        '429':
        

# --- truncated at 32 KB (55 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/relex/refs/heads/main/openapi/relex-events-api-openapi.yml