API parameters
API parameters make developers efficient when working with Pipeliner API. API parameters may vary from endpoint to endpoint.
Example
List of Query parameters
| Query parameter Name | Description | Endpoint Type |
|---|---|---|
validation-level | Turn offs validation on API requests | *.Create, *.Update, *.Delete |
after | Cursor, Used for Pagination of long lists. See pagination | *.List |
before | Cursor, Used for Pagination of long lists. See pagination | *.List |
expand | Expand related entity, to get immediate overview | *.List, *.Get |
filter | Filter data from API | *List |
filter-op | Filter operators for filtering data | *.List |
first | Number of entities to return from beginning of the result set. Max: 100. Default: 30 | *.List |
include_deleted | Returns deleted data Default: False | *.Get, *.List |
last | Return only the "last" number of entities from result set. When used with first parameter, then it returns last M records from the first N records. | *.List |
load-only | Loads only api_fields defined within this parameter. You can use multiple values separated via ',' colon. If not used, then all fields are returned. You can use dots '.' to specify load only fields in nested as well.
Example: | *.List |
order-by | Order by values. Use api_name of field to sort by ascending. Prefix api_name with '-' to descending sort. You can use multiple values separated via ',' colon
Example: | *.List |
rollback-method | Used in bulk updates/create, to rollback data that failed. 0 - rollback all, 1 - rollback only failed records. Default:0 See Bulk Update and Create | *.batchmethods |
Validation
Query parameter: validation-level
Helps when a developer doesn´t want to create data inside Pipeliner valid for some reason.
When the business has many required fields on the Entities, you might want to skip the validation of those fields and populate only fields that you actually need.
| Option | Description |
|---|---|
0(default) | Validate each field on the entity. Without even specifying this parameter, this is the general behavior of API - all API requests are automatically validated |
2 | Validate only changed fields in the actual request |
4 | Validate only system fields Custom/User-defined fields are not validated. Read about fields |
8 | Allows to override readonly fields |
16 | Allows setting entity on the deleted relationship. Example: user, an account might be deleted |
Example of Request
Using validation as query parameter. In this case example, the validation is skipped for options "4" and "16"
Example of invalid Data in Application
The Majority of Invalid entities in the application look normal, however, after updating the data the user will see the information about invalid data
Expand
Expand related entity. Use api_names of related fields. You can use multiple values separated via ',' comma. If not used, the URI link will be returned instead. You can use '.' to expand nested entities as well.
Example: expand=owner,sales_unit,account_relations.account
Expand parameter can be used also in case of custom lookup fields.
Filter, Filter-op
Filter
Use the API name of the field in braces to filter by this field. To do the advanced filter, use with combination with filter-op parameter.
Example: filter[api-field-name]=Example
Filter-op
Filter-op stands for filter operator. Below is the list of operators. You can combine several operators with filter[api-field-name] parameter
Last updated
