1. Oracle Eloqua REST APIREST API for Oracle Eloqua Marketing Cloud Service
  2. API Requests
  3. URL parameters

URL parameters

Request endpoints may also contain one or more URL parameters. Parameters are used to customize requests so as to more easily manipulate information in the database. Below you will find a list of standard URL request parameters.

Note:

The reporting API does not support request depth. Learn more about reporting API query options.

URL parameters are placed after an endpoint in the call's URL. The URL parameter set should be separated from the endpoint by a "?" symbol. If you add more than one URL parameter they should be separated from each other by a "&" symbol. For example:


GET [base URL]/API/Rest/2.0?page=5&count=30

Note: Most Eloqua API endpoints accept one or more of the below standard parameters, but not all endpoints support all parameters.

Name Description Constraints
depth Level of detail returned by the request. Learn more about the depth parameter. Possible values:
  • minimal
  • partial
  • complete

Example: ?depth=complete
count Maximum number of entities to return. Any whole number between 1 and 1000 inclusive.

Example: ?count=100
page Specifies which page of entities to return (the count parameter defines the number of entities per page). If the page parameter is not supplied, 1 will be used by default. Any positive whole number.

Example: ?page=3&count=10
search The search parameter specifies the search criteria to use to filter the results. The syntax for the search parameter is:

search={term}{operator}{value}

Learn more about the search URL parameter.

 {term} is the name of a field or property to filter on, {operator} is the comparison operator, and {value} is the value to compare the term with. If {term} and {operator} are not supplied, the term is compared to the value using the equality operator. Searches can be for exact full matches, or partial matches. A "*" symbol can be used after the {value} for partial matches. You can search with fields even if they are not returned at the depth being used. The following operators are supported on most endpoints:
  • = (Equal To)
  • != (Not equal to)
  • > (Greater than)
  • < (Less than)
  • >= (Greater than or Equal to)
  • <= (Less than or Equal to)

Example: GET .../data/contacts?search=id=1
sort Specifies the name of the property used to sort the returned entities. The value depends on the type of entity being sorted, with each entity having its own list of sortable properties.

Example: GET .../data/contacts?sort=firstName
dir Specifies the direction in which to sort the returned entities. "asc" for ascending or "desc" for descending.

Example: GET .../data/contacts?sort=firstName&dir=asc
orderBy Specifies the field by which list results are ordered, and the direction. The direction will default to ASC if not specified. Any valid asset parameter field.

Example: ?orderBy=createdAt

Example: ?orderBy=createdAt DESC

Example: ?orderBy=createdAt ASC
lastUpdatedAt When the asset was last updated. Will return deleted assets. For the majority of use cases, it's recommended to use updatedAt with the search URL parameter (e.g. ?search='updatedAt>518862600' A valid date/time value.

Example: ?lastUpdatedAt=518862600
viewId Specify a view id to filter results by view when retrieving Contact or Account data. A valid date/time value.

Example: .../data/contact/1?viewId=100002

Special cases:

  • statusCodeOverride

    Allows HTTP clients that don't support or expose HTTP status codes other than HTTP 200 OK to indicate that the server should always respond with a specific HTTP status code. If a value is supplied for the parameter, that value will be used as the status code. An example can been seen in the request below, which will always return HTTP 200 OK, regardless of whether or not the actual status is OK:

    
GET https://.../data/contact/123?statusCodeOverride=200