---
title: About the orderingId Parameter
slug: '147'
canonical_url: https://docs.coveo.com/en/147/
collection: index-content
source_format: adoc
---
# About the orderingId Parameter
All Push API requests, except for the [`Create a file container`](https://docs.coveo.com/en/43/) and [`Set the status of a Push source`](https://docs.coveo.com/en/35#update-the-status-of-a-push-source) requests, have an `orderingId` parameter.

When this parameter is optional, its value indicates the age of the request: a lower `orderingId` value corresponds to an older request.
By default, the Push API automatically sets this parameter to the current number of milliseconds since the Unix epoch (for example, `1506700606240`).
You can also provide your own optional `orderingId` parameter values when making Push API requests.
When doing so, make sure to increment the `orderingId` value with each new Push API request.
In essence, each Push API request must have an optional `orderingId` parameter value higher than the previous request, or [consistency issues](#potential-issues) will occur.

When the `orderingId` is required, as in the [`Delete old items`](https://docs.coveo.com/en/131/) and [`Delete old security identities`](https://docs.coveo.com/en/33/) requests, it has a different meaning.
In these two cases, the `orderingId` value indicates that the service should try to delete or disable any previously pushed [item](https://docs.coveo.com/en/210/) or [security identity](https://docs.coveo.com/en/240/) whose `orderingId` value is strictly lower than the one specified in the request.

> **Important**
>
> Unless you're setting your own `orderingId` values when pushing item or security identity updates, you should typically set the `orderingId` of a delete-older-than request to the current number of milliseconds elapsed since the Unix epoch, without adding any offset.
> Failing to do so may risk breaking the target [source](https://docs.coveo.com/en/246/) or [security identity provider](https://docs.coveo.com/en/242/).
> 
> For example, if you use an `orderingId` set to a moment ten years in the future to delete old items in a Push source, the [Coveo indexing pipeline](https://docs.coveo.com/en/184/) will reject any new items pushed to that source for the next ten years.
> If this mistake occurs, the only solution is to [recreate the source](https://docs.coveo.com/en/35#recreate-a-push-source-with-the-duplicate-feature).

**Example**

A Push API request whose optional `orderingId` value is `1506700606240` is older than a request whose optional `orderingId` value is `1506700606241`.

When performing a delete-items-older-than request, specifying `1506700606241` as the value for the required `orderingId` indicates that the service should try to delete all previously pushed items with optional `orderingId` values that are lower (that is, older) than `1506700606241`.

## Potential issues

Critical consistency issues may arise if you carelessly assign custom optional `orderingId` values in your Push API requests.
Therefore, you should make sure you know exactly what you're doing if you choose not to let the Push API automatically set the value of the optional `orderingId`.

**Example**

You perform a Push API request to add a new item in a Push source.
You decide to use `42` as the custom optional `orderingId` value for this request.

Later, you decide to perform a delete Push API request to remove that same item from the source.
This time, you decide to use `40` as the optional `orderingId` value.

Since `40` is lower (that is, older) than `42`, the Push API considers the delete request to predate the add request, which makes no sense.
Consequently, the delete operation fails at the indexing stage (with the `OUT_OF_SEQUENCE_OPERATION` error code in the source logs).

> **Important**
>
> The Crawling Module and the Coveo for Sitecore integration both use the Push API, and they both set their own opaque optional `orderingId` values (that is, they don't use milliseconds since the Unix epoch).
> Trying to evaluate those values is neither trivial, nor recommended.
> Therefore, performing manual Push API requests on Push sources managed by Crawling Modules or Coveo for Sitecore is strongly discouraged.