Stop a specific version of a meter
Stops all runnable NORMAL-mode runs for a specific version of a meter in Zuora Mediation.
By default, the API gracefully stops streaming meters by creating a savepoint. Streaming stops are asynchronous. A successful response means that the stop request was accepted and triggered; the meter version might temporarily remain in the STOPPING state before transitioning to PAUSED.
For batch meters and DEBUG runs, the job is canceled synchronously.
The caller must have at least one of the following permissions: RunMeters or ConfigureMetersAndEvents.
Force Stop is not supported when a run is already in the STOPPING state. STOPPING is a temporary transition state while the system processes a graceful stop. In most cases, the run quickly either returns to RUNNING if the graceful stop cannot be completed, or moves to its final terminal state. If Force Stop is required, retry the operation after the run exits the STOPPING state.
Path parameters
The numeric ID of the meter to stop.
The meter version to stop.
Query parameters
Controls whether the meter is stopped gracefully or forcefully.
If false or omitted, the API performs a graceful stop. For streaming meters, it creates a savepoint before stopping the job.
If true, the API immediately cancels the job without creating a savepoint. This might result in the loss of in-flight data, and the meter cannot resume from its previous state unless a valid recent savepoint exists for the corresponding meter.
Headers
No request body is required. If specified, use application/json.
Include the Accept-Encoding: gzip header to compress responses as a gzipped file. It can significantly reduce the bandwidth required for a response.
If specified, Zuora automatically compresses responses that contain over 1000 bytes of data, and the response contains a Content-Encoding header with the compression algorithm so that your client can decompress it.
Include the Content-Encoding: gzip header to compress a request. With this header specified, you should upload a gzipped file for the request payload instead of sending the JSON payload.
An entity ID. If you have Zuora Multi-entity enabled and the OAuth token is valid for more than one entity, you must use this header to specify which entity to perform the operation in. If the OAuth token is only valid for a single entity, or you do not have Zuora Multi-entity enabled, you should not set this header.
Comma separated IDs. If you have <a href="https://docs.zuora.com/en/zuora-platform/organization-and-entity-management/multi-org/overview-of-multi-org" target="_blank">Zuora Multi-Org</a> enabled, you can use this header to specify which orgs to perform the operation in. If you do not have Zuora Multi-Org enabled, you should not set this header.
The IDs must be a sub-set of the user's accessible orgs. If you specify an org that the user does not have access to, the operation fails. This header is important in Multi-Org (MO) setups because it defines the organization context under which the API should operate—mainly used for read access or data visibility filtering. If the header is not set, the operation is performed in scope of the user's accessible orgs.
A custom identifier for tracing the API call. If you set a value for this header, Zuora returns the same value in the response headers. This header enables you to associate your system process identifiers with Zuora API calls, to assist with troubleshooting in the event of an issue.
The value of this field must use the US-ASCII character set and must not include any of the following characters: colon (:), semicolon (;), double quote ("), and quote (').
Response
Meter stop request accepted successfully.
Changes
Changed in 1 of the 4 revisions of this API.1
- ○
endpoint added
endpoint-added
- ○