What authentication does the CloudConvert API use?

The spec defines two schemes: a personal bearer token for first-party apps and an OAuth2 flow for user-delegated access. Both are passed as Authorization: Bearer <token>. Through Jentic, tokens are stored encrypted and injected at execution time.

Can I retry a failed CloudConvert task?

Yes. POST /tasks/{taskId}/retry re-runs a failed task with the same parameters and produces a new task ID. This is the standard recovery path for transient errors such as upstream import failures.

How do I cancel a running CloudConvert job?

Cancel each pending task with POST /tasks/{taskId}/cancel. Tasks that have already completed cannot be cancelled, but pending and running tasks transition to a cancelled state and stop consuming credits.

How do I run a CloudConvert job through Jentic?

Run jentic search 'convert a file with CloudConvert', load the createJob operation, and execute with the source URL and output_format. Jentic handles the bearer or OAuth2 token from the stored credential.

Is there a sandbox environment for CloudConvert?

Yes. The spec lists https://sandbox.api.cloudconvert.com/v2 as a server. Use it to validate task chains and webhook flows before pointing the client at the production https://api.cloudconvert.com/v2 base URL.

Can I limit what my agent is allowed to do with the CloudConvert API?

Yes. Because your Jentic One instance is self-hosted, your own rules decide which CloudConvert operations and credentials the agent can use. CloudConvert's job and task IDs are ephemeral rather than fixed resources, so you scope the agent by the operations you grant it, such as creating a job or reading a task. Operations like cancelling or retrying a task or registering a webhook are only reachable if you choose to include them.