Cognite

aid: cognite
accessModel:
  pricing: unknown
  onboarding: self-serve
  trial: false
  try_now: false
  public: false
  label: Self-serve signup
  confidence: medium
  source:
  - authentication
  generated: '2026-07-22'
  method: derived
image: https://kinlane-images.s3.amazonaws.com/shared/apis-json/icons/cognite.png
name: Cognite
description: Cognite is an industrial AI and data platform provider whose core product, Cognite Data Fusion (CDF), contextualizes
  and integrates data from OT, IT, and ET systems across oil and gas, energy, manufacturing, and mining industries. CDF exposes
  a comprehensive REST API covering assets, time series, events, files, 3D models, data modeling, entity matching, transformations,
  functions, and workflows, with SDKs available for Python, JavaScript, Java, .NET, and Rust.
type: Index
url: https://raw.githubusercontent.com/api-evangelist/cognite/refs/heads/main/apis.yml
tags:
- Industrial IoT
- Manufacturing
- Industrial Data
- Digital Twin
- Asset Management
- Time Series
- Industrial AI
created: '2026-06-05'
modified: '2026-06-05'
specificationVersion: '0.19'
apis:
- aid: cognite:cognite-data-fusion-api
  name: Cognite Data Fusion API
  description: The Cognite Data Fusion (CDF) REST API provides programmatic access to industrial data including assets, time
    series, events, files, sequences, 3D models, data modeling spaces and instances, entity matching for contextualization,
    SQL transformations, serverless functions, workflow orchestration, and SAP writeback. Supports OAuth 2.0 and API key authentication
    against project-scoped endpoints.
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - Industrial Data
  - Time Series
  - Asset Management
  - Digital Twin
  - Data Modeling
  - Contextualization
  - REST
  properties:
  - url: https://api-docs.cognite.com/
    type: Documentation
  - url: https://docs.cognite.com/
    type: Portal
- aid: cognite:cognite-3d-asset-mapping-api
  name: Cognite 3D Asset Mapping API
  description: The 3D Asset Mapping API from Cognite — 5 operation(s) for 3d asset mapping.
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - 3D Asset Mapping
  properties:
  - type: OpenAPI
    url: openapi/cognite-3d-asset-mapping-api-openapi.yml
- aid: cognite:cognite-3d-files-api
  name: Cognite 3D Files API
  description: The 3D Files API from Cognite — 2 operation(s) for 3d files.
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - 3D Files
  properties:
  - type: OpenAPI
    url: openapi/cognite-3d-files-api-openapi.yml
- aid: cognite:cognite-3d-jobs-api
  name: Cognite 3D Jobs API
  description: The 3D Jobs API from Cognite — 6 operation(s) for 3d jobs.
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - 3D Jobs
  properties:
  - type: OpenAPI
    url: openapi/cognite-3d-jobs-api-openapi.yml
- aid: cognite:cognite-3d-model-revisions-api
  name: Cognite 3D Model Revisions API
  description: The 3D Model Revisions API from Cognite — 11 operation(s) for 3d model revisions.
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - 3D Model Revisions
  properties:
  - type: OpenAPI
    url: openapi/cognite-3d-model-revisions-api-openapi.yml
- aid: cognite:cognite-3d-models-api
  name: Cognite 3D Models API
  description: The 3D Models API from Cognite — 4 operation(s) for 3d models.
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - 3D Models
  properties:
  - type: OpenAPI
    url: openapi/cognite-3d-models-api-openapi.yml
- aid: cognite:cognite-annotations-api
  name: Cognite Annotations API
  description: "Annotations reflect contextual information in base CDF resource types, such as Files and Time series, that\
    \ are not\npresent on the object itself. The benefits of the annotations concept are threefold:\n\n- The annotations concept\
    \ is a good fit for enriching the base resources themselves, so that the overall data\n  quality is higher in a given\
    \ project.\n- It is also a good fit for building reference datasets for data problems uniformly across customer projects.\n\
    \  Product teams can then use those reference datasets to train machine learning models or validate\nthe\n  performance\
    \ of their algorithms on actual customer data.\n- Given a uniform way of labelling similar concepts across projects, it\
    \ becomes easy for apps to agree on a consistent\n  visual representation of those concepts."
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - Annotations
  properties:
  - type: OpenAPI
    url: openapi/cognite-annotations-api-openapi.yml
- aid: cognite:cognite-assets-api
  name: Cognite Assets API
  description: "The assets resource type stores digital representations of objects or\ngroups of objects from the physical\
    \ world. Assets are organized in hierarchies.\nFor example, a water pump asset can be a part of a subsystem asset on an\n\
    oil platform asset.\n\n## Rate and concurrency limits\n\nBoth the rate of requests (denoted as request per second, or\
    \ â\x80\x98**rps**â\x80\x99) and the number of concurrent (parallel) requests are governed by limits,\nfor all CDF API\
    \ endpoints.  If a request exceeds one of the limits,\nit will be throttled with a `429: Too Many Requests` response.\
    \ More on limit types\nand how to avoid being throttled is described\n[here](https://docs.cognite.com/dev/concepts/resource_throttling).\n\
    \nLimits are defined at both the overall API service level, and on the API endpoints belonging to the service.\\\nSome\
    \ types of requests consume more resources (compute, storage IO) than others, and where a service handles\nmultiple concurrent\
    \ requests with varying resource consumption.\nFor example, â\x80\x98CRUDâ\x80\x99 type requests (**C**reate, **R**etrieve,\
    \ **R**equest ByIDs, **U**pdate and **D**elete) are far less resource\nintensive than â\x80\x98Analyticalâ\x80\x99 type\
    \ requests (List, Search and Filter) and in addition, the most resource\nintensive Analytical endpoint of all, Aggregates,\
    \ receives its own request budget within the overall Analytical request budget.\\\nThe version 1.0 limits for the overall\
    \ API service and its constituent endpoints are illustrated in the diagram below.\\\nThese limits are subject to change,\
    \ pending review of changing consumption patterns and resource availability over time:\n\n<img src=\"https://apps-cdn.cogniteapp.com/@cognite/docs-portal-images/1.0.0/images/api-docs/AssetsLimitsFeb2023.png\"\
    \ alt=\" \" width=\"80%\"/>\n\n### Translating RPS into data speed\nA single request may retrieve up to 1000 items.  In\
    \ the context of Assets, 1 item = 1 asset record\\\nTherefore, the maximum theoretical data speed at the top API service\
    \ level is 200,000 items per second for all consumers,\nand 150,000 for a single identity or client in a project.\n\n\
    ### Use of Partitions / Parallel Retrieval\nAs a general guidance, Parallel Retrieval is a technique that should be used\
    \ where due to query complexity, retrieval of data in a\nsingle request session turns out to be slow.  By parallelizing\
    \ such requests, data retrieval performance can be tuned to meet the\nclient application needs.  Parallel retrieval may\
    \ also be used where retrieval of large sets of data is required, up to the\ncapacity limits defined for a given API service.\
    \  For example (using the Assets API request budget):\n\n* A single request may retrieve up to 1000 items\n* Up to 23\
    \ requests per second may be issued for an analytical query (per identity), such as when using /list or /filter API endpoints\n\
    * This provides a theoretical maximum of 23,000 items read per second per identity\n* The query complexity may result\
    \ in it taking longer than 1s to read or write 1000 items in a single request\n* Therefore, it is appropriate to specify\
    \ the query to retrieve a lower number of items per request, and retrieve more items in parallel, up to the theoretical\
    \ maximum performance of 23,000 items per second.\n\n**Important Note:**\nParallel retrieval should be only used in situations\
    \ where, due to query complexity,\na single request flow provides data retrieval speeds that are significantly less than\
    \ the theoretical maximum.\\\nParallel retrieval does not act as a speed multiplier on optimally running queries.  Regardless\
    \ of the number\nof concurrent requests issued, the overall requests per second limit still applies.\\\nSo for example,\
    \ a single request returning data at approximately 18,000 items per second will only\nbenefit from adding a second parallel\
    \ request, the capacity of which goes somewhat wasted\nas only an additional 5,000 items per second will return before\
    \ the request rate budget limit is reached."
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - Assets
  properties:
  - type: OpenAPI
    url: openapi/cognite-assets-api-openapi.yml
- aid: cognite:cognite-connections-api
  name: Cognite Connections API
  description: The Connections API from Cognite — 3 operation(s) for connections.
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - Connections
  properties:
  - type: OpenAPI
    url: openapi/cognite-connections-api-openapi.yml
- aid: cognite:cognite-containers-api
  name: Cognite Containers API
  description: The Containers API from Cognite — 9 operation(s) for containers.
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - Containers
  properties:
  - type: OpenAPI
    url: openapi/cognite-containers-api-openapi.yml
- aid: cognite:cognite-data-models-api
  name: Cognite Data models API
  description: The Data models API from Cognite — 3 operation(s) for data models.
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - Data models
  properties:
  - type: OpenAPI
    url: openapi/cognite-data-models-api-openapi.yml
- aid: cognite:cognite-data-point-subscriptions-api
  name: Cognite Data point subscriptions API
  description: "A data point subscription is a way to listen to changes to time series data points, in ingestion order.\n\n\
    A single subscription can listen to many time series, and a time series can be part of many subscriptions.\n\nYou listen\
    \ to subscriptions by calling the â\x80\x9Clist subscription dataâ\x80\x9C endpoint. It will return\na list of data point\
    \ upserts and deleted ranges, together with a cursor to retrieve the next\nbatch of updates. Updates written since the\
    \ creation of the subscription, up to 7 days ago, can be\nretrieved through the subscription.\n\nSubscriptions can be\
    \ defined explicitly through a list of time series external ids and\ninstance ids, or implicitly through a filter. The\
    \ filter is a subset of the advanced filter\nquery in the regular â\x80\x9Ctime series searchâ\x80\x9C endpoint.\n\nPartitions:\n\
    Subscriptions can be further divided into a number of partitions, for the purpose of\nfetching subscription data in parallel.\
    \ Each partition will return data in ingestion order,\nbut the order between partitions is not guaranteed.\n\nLimitations:\n\
    - Each subscription can have at most 10000 time series.\n- A time series can be part of at most 10 subscriptions.\n- A\
    \ project can have at most 1000 subscriptions, of which 100 are filter subscriptions.\n- Time series with security categories\
    \ can not be shown in filter subscriptions.\n- Time series with neither external id nor instance id cannot be added to\
    \ non-filter subscriptions.\n- The number of partitions cannot be changed after creation.\n\nAccess control:\nYou need\
    \ READ access to subscriptions ACL to read/list\nsubscriptions or list data, and you need WRITE access to create/update/delete\
    \ subscriptions.\nFurthermore, you need READ access to the time series you want to get updates from.\nFor filter subscriptions,\
    \ you either need READ access to all time series, or the filter must\nbe restricted according to your access rights (e.g.\
    \ by filtering on specific data set IDs).\n\nSubscriptions can have data sets that allow for more granular access\ncontrol.\
    \ The data set on a subscription does not influence the data\nstream, but allows you to restrict who can read/update the\
    \ subscription.\n\nName of ACL:\n  `timeSeriesSubscriptionsAcl`\n\nSupported actions:\n  - `READ`\n  - `WRITE`\n\nExample\
    \ capabilities:\n```\n[\n    {\"timeSeriesAcl\":{\"actions\":[\"READ\"], \"scope\":{\"all\":{}}}},\n    {\"timeSeriesSubscriptionsAcl\"\
    :{\"actions\":[\"WRITE\", \"READ\"], \"scope\":{\"all\":{}}}}\n]\n```"
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - Data point subscriptions
  properties:
  - type: OpenAPI
    url: openapi/cognite-data-point-subscriptions-api-openapi.yml
- aid: cognite:cognite-data-products-api
  name: Cognite Data products API
  description: "Data products are governed, ready-for-consumption data assets derived from data domains, following data mesh\
    \ principles.\n\n  **Key characteristics:**\n  - **Clear ownership**: Defined data product owners with explicit access\
    \ roles and accountability\n  - **Rich metadata**: Comprehensive data modeling views, usage terms, access permissions,\
    \ and descriptive\ndocumentation\n  - **Self-service consumption**: Discoverable and well-documented for autonomous data\
    \ consumer access\n  - **Version management**: Immutable data modeling view versions with governed schemas and updatable\n\
    metadata\n\n  Data products act as a governance layer around data modeling, establishing trust and reliability\nfor business\
    \ decisions through clear ownership, comprehensive metadata, and standardized access patterns.\n\n  **Space ownership**:\
    \ A data product owns a schema space. The data modeling views that the data product\ngoverns live in that schema space.\
    \ The schema space is exclusively owned by the data product."
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - Data products
  properties:
  - type: OpenAPI
    url: openapi/cognite-data-products-api-openapi.yml
- aid: cognite:cognite-data-sets-api
  name: Cognite Data sets API
  description: 'Data sets let you document and track data lineage, ensure data integrity, and allow 3rd parties to write their
    insights securely back to a Cognite Data Fusion (CDF) project.



    Data sets group and track data by its source. For example, a data set can contain all work orders originating from SAP.
    Typically, an organization will have one data set for each of its data ingestion pipelines in CDF.



    A data set consists of metadata about the data set, and the data objects that belong to the data set. Data objects, for
    example events, files, and time series, are added to a data set through the `dataSetId` field of the data object. Each
    data object can belong to only one data set.



    To learn more about data sets, see [getting started guide](https://docs.cognite.com/cdf/data_governance/concepts/datasets/)'
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - Data sets
  properties:
  - type: OpenAPI
    url: openapi/cognite-data-sets-api-openapi.yml
- aid: cognite:cognite-destinations-api
  name: Cognite Destinations API
  description: 'A hosted extractor writes to a **destination**. The destination contains credentials for CDF, and additional
    information about where the data should land, such as data set ID.

    Multiple jobs can share a single destination, in which case requests will be combined, reducing the number of requests
    made to CDF APIs. Metrics are still reported for each individual job.'
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - Destinations
  properties:
  - type: OpenAPI
    url: openapi/cognite-destinations-api-openapi.yml
- aid: cognite:cognite-diagrams-api
  name: Cognite Diagrams API
  description: The Diagrams API from Cognite — 6 operation(s) for diagrams.
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - Diagrams
  properties:
  - type: OpenAPI
    url: openapi/cognite-diagrams-api-openapi.yml
- aid: cognite:cognite-document-ai-api
  name: Cognite Document AI API
  description: The Document AI API from Cognite — 2 operation(s) for document ai.
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - Document AI
  properties:
  - type: OpenAPI
    url: openapi/cognite-document-ai-api-openapi.yml
- aid: cognite:cognite-document-parsing-api
  name: Cognite Document parsing API
  description: The Document parsing API from Cognite — 1 operation(s) for document parsing.
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - Document parsing
  properties:
  - type: OpenAPI
    url: openapi/cognite-document-parsing-api-openapi.yml
- aid: cognite:cognite-document-preview-api
  name: Cognite Document preview API
  description: 'The document preview service is a utility API that can render most document types as an image or PDF.

    This can be very helpful if you want to display a preview of a file in a frontend, or for other

    tasks that require one of these formats.


    For both rendered formats there is a concept of a page. The actual meaning of a page depends on

    the source document. E.g. an image will always have exactly one page, while a spreadsheet

    will typically have one page representing each individual sheet.


    The document preview service can only generate preview for document sizes that do not

    exceed 150 MiB. Trying to preview a larger document will give an error.


    ### File type support

    Previews can be created for the following types of files:

    - PDF files

    - Spreadsheets, documents and presentations from the Microsoft and Libre Office office suites

    - Images'
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - Document preview
  properties:
  - type: OpenAPI
    url: openapi/cognite-document-preview-api-openapi.yml
- aid: cognite:cognite-documents-api
  name: Cognite Documents API
  description: "A document is a file that has been indexed by the document search engine.\nEvery time a file is uploaded,\
    \ updated or deleted in the Files API, it will also\nbe scheduled for processing by the document search engine. After\
    \ some processing,\nit will be possible to search for the file in the document search API.\n\nThe document search engine\
    \ is able to extract content from a variety of document\ntypes, and perform classification, contextualization and other\
    \ operations on the\nfile. This extracted and derived information is made available in the form of a\n`Document` object.\n\
    \nThe document structure consists of a selection of derived fields, such as the\n`title`, `author` and `language` of the\
    \ document, plus some of the original fields\nfrom the raw file. The fields from the raw file can be found in the\n`sourceFile`\
    \ structure. The derived fields are described in more detail below.\n\n### Derived fields\n\n#### title\nSome document\
    \ types (such as PDFs) contain additional metadata fields. If the\ndocument contains its title as part of this metadata,\
    \ this field will be populated\nwith that title.\n\nNote that we do not currently extract the title from the document\
    \ content itself.\nIf there is a need for this, we may consider adding such functionality in the future.\n\n#### author\n\
    Similar to the `title` field, the author field is another field that can often be\nextracted from the document's metadata.\n\
    \n#### producer\nThe `producer` field also exists in the document metadata. It contains information\nabout the software\
    \ or the system that was used to create the document.\n\n#### createdTime\nThe `createdTime` we assign to the document\
    \ is not exactly the same as the one found\nin the Files API. We first try to extract the created time from the document\
    \ metadata.\nIf the document does not contain such a timestamp, we fall back to the time set in\nthe Files API.\n\n####\
    \ mimeType\nIf there is a mime type set in on the file in the Files API, this field will be set\nto the same mime type.\
    \ If there is no mime type set on the file, we will try to\nauto-detect it.\n\n#### extension\nThis field contains the\
    \ extension of the file, derived from the file name. For\ninstance, if the file name is `My Document.docx`, the `extension`\
    \ field will contain\n`docx`.\n\n#### pageCount\nContains the number of pages in the document, if possible to determine.\n\
    \n#### type\nThe `type` field contains a high level file type, derived from the mime type. Mime\ntypes are not that pleasant\
    \ to look at, and not always easy to understand. That is\nwhy we map the mime types into more user-friendly types. Below\
    \ is the list of types\ncurrently returned, but be aware that this list may be extended in the future.\n\n- `Document`:\
    \ Document files from Microsoft Word or similar word processing software.\n- `PDF`: PDF files.\n- `Spreadsheet`: Files\
    \ from Microsoft Excel or similar spreadsheet software.\n- `Presentation`: Slides from Microsoft Powerpoint or similar.\n\
    - `Image`: Any kind of image such as PNG or JPG files.\n- `Video`: Any kind of video such as MOV or MP4 files.\n- `Tabular\
    \ data`: Csv, tsv and other kinds of tabular data files.\n- `Plain text`: Plain text files.\n- `Compressed`: ZIP files\
    \ and other kinds of compressed archive files.\n- `Script`: Program code such as python or matlab.\n- `Other`: Anything\
    \ that doesn't fit in any of the above types.\n\n#### geoLocation\nIf there is a geolocation set on the file in the Files\
    \ API, then this field will contain\nthe same geolocation. If there is no explicitly assigned geolocation, the document\n\
    processing system will try to detect a location using two different techniques;\n\n1. We will extract locations from files\
    \ that contain embedded GPS locations. Photos and\n   videos often have this kind of metadata.\n2. We will look at related\
    \ assets that have locations, and assign the same location(s) to\n   the document.\n\n### File type support\n\nWe create\
    \ a document for each uploaded file, but only derive data from certain files.\n\nThe following file types are eligible\
    \ for further data extraction & enrichment:\n- PDF files\n- Spreadsheets, documents, and presentations from the Microsoft,\
    \ Libre Office and macOS office suites\n- Plain text files\n- Images"
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - Documents
  properties:
  - type: OpenAPI
    url: openapi/cognite-documents-api-openapi.yml
- aid: cognite:cognite-engineering-diagrams-api
  name: Cognite Engineering diagrams API
  description: The Engineering diagrams API from Cognite — 4 operation(s) for engineering diagrams.
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - Engineering diagrams
  properties:
  - type: OpenAPI
    url: openapi/cognite-engineering-diagrams-api-openapi.yml
- aid: cognite:cognite-entities-api
  name: Cognite Entities API
  description: The Entities API from Cognite — 4 operation(s) for entities.
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - Entities
  properties:
  - type: OpenAPI
    url: openapi/cognite-entities-api-openapi.yml
- aid: cognite:cognite-entity-matching-api
  name: Cognite Entity matching API
  description: The entity matching contextualization endpoints lets you match CDF resources. For example, you can match time
    series to assets. The model uses similarity between string-fields from the source and the target to find potential matches,
    for instance the source name and the target name. The exact algorithm may change over time.
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - Entity matching
  properties:
  - type: OpenAPI
    url: openapi/cognite-entity-matching-api-openapi.yml
- aid: cognite:cognite-events-api
  name: Cognite Events API
  description: "Events objects store complex information about multiple assets over a time period.\nTypical types of events\
    \ that would be stored in this service might include Alarms, Process Data, and Logs.\\\nFor the storage of low volume,\
    \ manually generated, schedulable activities (such as maintenance schedules,\nwork orders or other â\x80\x98appointmentâ\x80\
    \x99 type activities, the Data Modeling service is now recommended.\n\n#### Important Note:\nEvents and Time Series are\
    \ somewhat closely related in that both are high volume types of data,\ncapable of recording data in microsecond resolutions.\
    \  However, Events is not recommended as a Time Series store,\nsuch as where the data flow is from a single instance of\
    \ sensors (i.e. temperature, pressure, voltage),\nsimulators or state machines (on, off, disconnected, etc).\\\nTime Series\
    \ offers very low latency read and write performance, as well as specialised filters and aggregations that\nare tailored\
    \ to the analysis of time series data.\n\nAn eventâ\x80\x99s time period is defined by a start time and end time, both\
    \ millisecond timestamps since the UNIX epoch.\nThe timestamps can be in the future. In addition, events can have a text\
    \ description as well as arbitrary metadata and properties.\\\nWhen storing event information in metadata, it should be\
    \ considered that all data is stored as string format.\n\n#### Note:\nIn Events API, timestamps are treated as strings\
    \ when added to\nmetadata fields and arenâ\x80\x99t converted to the userâ\x80\x99s local time zone.\n\n**Caveats:**\\\
    \nDue to the eventually consistent nature of Asset IDs stored in Events,\nit should be noted that Asset ID references\
    \ obtained from the Events API may\noccasionally be invalid (such as if an Asset ID is deleted,\nbut the reference to\
    \ that ID remains in the Event record for a time).\n\nAsset references obtained from an event - through asset ids - may\
    \ be\ninvalid, simply by the non-transactional nature of HTTP.\nThey are maintained in an eventual consistent manner.\n\
    \n## Rate and concurrency limits\n\nBoth the rate of requests (denoted as request per second, or â\x80\x98**rps**â\x80\
    \x99) and the number of concurrent (parallel) requests are governed by limits,\nfor all CDF API endpoints.  If a request\
    \ exceeds one of the limits,\nit will be throttled with a `429: Too Many Requests` response. More on limit types\nand\
    \ how to avoid being throttled is described\n[here](https://docs.cognite.com/dev/concepts/resource_throttling).\n\nLimits\
    \ are defined at both the overall API service level, and on the API endpoints belonging to the service.\\\nSome types\
    \ of requests consume more resources (compute, storage IO) than others, and where a service handles\nmultiple concurrent\
    \ requests with varying resource consumption.\nFor example, â\x80\x98CRUDâ\x80\x99 type requests (**C**reate, **R**etrieve,\
    \ **R**equest ByIDs, **U**pdate and **D**elete) are far less resource\nintensive than â\x80\x98Analyticalâ\x80\x99 type\
    \ requests (List, Search and Filter) and in addition, the most resource\nintensive Analytical endpoint of all, Aggregates,\
    \ receives its own request budget within the overall Analytical request budget.\\\nThe version 1.0 limits for the overall\
    \ API service and its constituent endpoints are illustrated in the diagram below.\\\nThese limits are subject to change,\
    \ pending review of changing consumption patterns and resource availability over time:\n\n<img src=\"https://apps-cdn.cogniteapp.com/@cognite/docs-portal-images/1.0.0/images/api-docs/EventsLimitsNov23.png\"\
    \ alt=\" \" width=\"80%\"/>\n\n### Translating RPS into data speed\nA single request may retrieve up to 1000 items.  In\
    \ the context of Events, 1 item = 1 event record\\\nTherefore, the maximum theoretical data speed at the top API service\
    \ level is 200,000 items per second for all consumers,\nand 150,000 for a single identity or client in a project.\n\n\
    ### Use of Partitions / Parallel Retrieval\nAs a general guidance, Parallel Retrieval is a technique that should be used\
    \ where due to query complexity, retrieval of data in a\nsingle request session turns out to be slow.  By parallelizing\
    \ such requests, data retrieval performance can be tuned to meet the\nclient application needs.  Parallel retrieval may\
    \ also be used where retrieval of large sets of data is required, up to the\ncapacity limits defined for a given API service.\
    \  For example (using the Events API request budget):\n\n* A single request may retrieve up to 1000 items\n* Up to 23\
    \ requests per second may be issued for an analytical query (per identity), such as when using /list or /filter API endpoints\n\
    * This provides a theoretical maximum of 23,000 items read per second per identity\n* The query complexity may result\
    \ in it taking longer than 1s to read or write 1000 items in a single request\n* Therefore, it is appropriate to specify\
    \ the query to retrieve a lower number of items per request, and retrieve more items in parallel, up to the theoretical\
    \ maximum performance of 23,000 items per second.\n\n**Important Note:**\nParallel retrieval should be only used in situations\
    \ where, due to query complexity,\na single request flow provides data retrieval speeds that are significantly less than\
    \ the theoretical maximum.\\\nParallel retrieval does not act as a speed multiplier on optimally running queries.  Regardless\
    \ of the number\nof concurrent requests issued, the overall requests per second limit still applies.\\\nSo for example,\
    \ a single request returning data at approximately 18,000 items per second will only\nbenefit from adding a second parallel\
    \ request, the capacity of which goes somewhat wasted\nas only an additional 5,000 items per second will return before\
    \ the request rate budget limit is reached."
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - Events
  properties:
  - type: OpenAPI
    url: openapi/cognite-events-api-openapi.yml
- aid: cognite:cognite-extraction-pipelines-api
  name: Cognite Extraction Pipelines API
  description: Extraction Pipeline objects represent the applications and software that are deployed to ingest operational
    data into CDF.  An extraction pipeline can consist of a number of different software components between the source system
    and CDF. The extraction pipeline object represents the software component that actually sends the data to CDF. Two examples
    are Cognite extractors and third party ETL tools such as Microsoft Azure or Informatica PowerCenter
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - Extraction Pipelines
  properties:
  - type: OpenAPI
    url: openapi/cognite-extraction-pipelines-api-openapi.yml
- aid: cognite:cognite-extraction-pipelines-config-api
  name: Cognite Extraction Pipelines Config API
  description: Extraction Pipelines Configs are configuration file revisions tied to an extraction pipeline. Users can create
    new configuration revisions, and extractors can fetch the latest, making it easy to deploy configuration files from source
    control, automated scripts, etc.
  humanURL: https://api-docs.cognite.com/
  baseURL: https://api.cognitedata.com
  tags:
  - Extraction Pipelines Config
  properties:
  - type: OpenAPI
    url: openapi/cognite-extraction-pipelines-config-api-openapi.yml
- aid: cognite:cognite-extraction-pipelines-runs-api
  name: Cognite Extraction Pipelines Runs API
  description: "Extraction Pipelines Runs are CDF objects to store statuses related to an extraction pipeline. The supported\
    \ statuses are: success, failure and seen. The statuses are related to two different types of operation of the extraction\
    \ pipeline

# --- truncated at 32 KB (103 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/cognite/refs/heads/main/apis.yml