Migrate from CloudConvert to ChangeThisFile

CloudConvert is a capable, well-documented conversion API, and for a lot of workloads it is also the cheaper one. This guide is written to help you decide, not to sell you a migration: it shows the two billing models side by side, the volumes where each one wins, and the exact code changes if you do switch.

The short version: the two products price different things. CloudConvert meters work - credits scale with conversion type and processing time. ChangeThisFile meters calls - one conversion is one unit whether it is a 40 KB JPEG or a 300-page PDF that takes four minutes. Migrating pays off when your files are expensive in CloudConvert's unit and cheap in ChangeThisFile's. It costs you money when the reverse is true.

Why people migrate - and when they shouldn't

The real reason to migrate: unit mismatch. CloudConvert's published base costs are 1 credit for a general conversion, 2 for Office-to-PDF, and 4 for PDF-to-Office, plus one additional credit for every extra minute a job runs beyond the first. A 200-page PDF-to-DOCX that takes three minutes is therefore several credits. On ChangeThisFile the same file is one conversion, the same as a thumbnail resize. If your pipeline is weighted toward PDF-to-Office, large documents, or long video, the flat unit is worth real money.

Async overhead for simple use cases. CloudConvert's job system is powerful but verbose: create a job, get a job ID, poll until status is finished or register a webhook, then download from an export URL. For "convert this file and give it back" workflows that is real boilerplate you can delete (see the before/after below). This is a maintenance argument, not a cost argument.

Who should stay on CloudConvert - and it is a long list:

• Your conversions are fast and cheap in credits. Image and general conversions that finish in under a minute cost 1 credit. At that shape CloudConvert is roughly 3-4x cheaper per conversion than ChangeThisFile at every volume we compared. Do not migrate to save money here; you will spend more.
• You rely on the free tier. CloudConvert's free tier is 10 credits per day, which is about 300 a month. ChangeThisFile's free tier is 25 a month. CloudConvert's is more than ten times larger.
• You need webhooks, or S3/GCS input and output. ChangeThisFile's API is synchronous and returns bytes in the response body. It has no webhooks and no cloud-storage tasks.
• You need custom video encoding. CloudConvert exposes bitrate, codec, and encoder options. ChangeThisFile does not.
• You need a contractual SLA. ChangeThisFile publishes no SLA outside Enterprise.
• You convert niche formats. ChangeThisFile covers roughly 1,000 conversion routes. CloudConvert's catalog is broader for CAD, EXR, HDR, and industry-specific formats.
• You run above 200,000 conversions a month. That is the top of ChangeThisFile's published ladder; beyond it you are in a sales conversation, while CloudConvert's rate curve keeps going to a million and beyond.

Cost comparison: the honest math

You cannot compare these two on a single number, because a CloudConvert credit is not a conversion. Below are both workloads that matter, priced from each vendor's published rates as of 26 July 2026.

ChangeThisFile's ladder (the quotas the API actually enforces): Free 25/month, Hobby $29 for 1,500, Startup $99 for 6,000, Scale $499 for 40,000, Growth $1,999 for 200,000. Every plan hard-stops at its quota with HTTP 429 - there is no overage billing, so you must size your plan above your peak month, not your average.

Workload A: fast image and general conversions (1 CloudConvert credit each)

If this is your workload, the migration is a cost increase. The only reasons left to do it are the simpler synchronous API and the predictable unit - both real, neither worth 3x to most teams.

Workload B: PDF-to-Office (4 CloudConvert credits each)

The pattern generalises: the more expensive a file is in CloudConvert's unit - PDF-to-Office, Office-to-PDF, multi-minute video, very large documents - the better the flat per-conversion price looks. Anything that finishes fast and costs one credit is cheaper to leave where it is.

Two caveats on these numbers. CloudConvert quoted us EUR net of 19% German VAT because the request geolocated to the EU; a US buyer may be quoted in USD. We have not applied an exchange rate. The 3-4x gaps in Workload A are wide enough that no plausible rate closes them, but the Workload B rows are close - price both sides in your own currency before you decide. CloudConvert also sells one-time credit packages that never expire (about €0.015/credit at 1,000, falling to €0.005 at a million), which is the better shape if your volume is spiky rather than monthly.

To estimate your own case: open your CloudConvert dashboard and read actual credit consumption, not request count. Divide credits by conversions to get your real credits-per-conversion. If it is close to 1, stay. If it is 3 or more, run the numbers again with the tables above.

API endpoint mapping

Source format is auto-detected from the filename extension — you don't need to specify it explicitly.

Code migration: BEFORE and AFTER

Here's a complete DOCX-to-PDF conversion in Python, before and after:

# BEFORE: CloudConvert (async job + polling + download)
import cloudconvert
import requests
import time

cloudconvert.configure(api_key='your_cloudconvert_key')

job = cloudconvert.Job.create(payload={
    'tasks': {
        'import-my-file': {
            'operation': 'import/upload'
        },
        'convert-my-file': {
            'operation': 'convert',
            'input': 'import-my-file',
            'output_format': 'pdf'
        },
        'export-my-file': {
            'operation': 'export/url',
            'input': 'convert-my-file'
        }
    }
})

# Upload the file
upload_task = next(t for t in job['tasks'] if t['operation'] == 'import/upload')
with open('document.docx', 'rb') as f:
    cloudconvert.Task.upload(file_name='document.docx', task=upload_task, file=f)

# Poll until done
while True:
    job = cloudconvert.Job.find(id=job['id'])
    if job['status'] == 'finished':
        break
    if job['status'] == 'error':
        raise Exception('Conversion failed')
    time.sleep(2)

# Download result
export_task = next(t for t in job['tasks'] if t['operation'] == 'export/url')
download_url = export_task['result']['files'][0]['url']
result = requests.get(download_url)
with open('document.pdf', 'wb') as f:
    f.write(result.content)

# AFTER: ChangeThisFile (one call, synchronous)
import requests

response = requests.post(
    'https://changethisfile.com/v1/convert',
    headers={'Authorization': 'Bearer ctf_sk_your_key'},
    files={'file': open('document.docx', 'rb')},
    data={'target': 'pdf'}
)
with open('document.pdf', 'wb') as f:
    f.write(response.content)

The CloudConvert version is ~35 lines. The ChangeThisFile version is 9 lines. Both do exactly the same thing.

Auth and token migration

1. Get your ChangeThisFile API key: Visit changethisfile.com/v1/keys/free — no credit card required. Your key starts with ctf_sk_.
2. Update your authorization header: Replace Authorization: Bearer {cloudconvert_key} with Authorization: Bearer ctf_sk_{your_key}.
3. Remove SDK imports: Delete import cloudconvert and remove the cloudconvert.configure() call. ChangeThisFile works with any HTTP client.
4. Store the key securely: Add CTF_API_KEY=ctf_sk_... to your .env file and reference it via environment variable, same as you did with your CloudConvert key.
5. Retire your CloudConvert key: Once your integration is confirmed working, revoke the old API key from your CloudConvert dashboard to avoid any accidental usage charges.

Webhook migration

CloudConvert supports webhooks that fire when a job completes. ChangeThisFile uses a synchronous API — the converted file is returned directly in the HTTP response, so webhooks are not needed or supported.

If you used CloudConvert webhooks for async notification: Remove the webhook handler. The await response or response.content is your completion signal. Your code that ran inside the webhook handler should run after the requests.post() call returns.

If you used CloudConvert webhooks for reliability (retry on failure): Wrap the ChangeThisFile call in your own retry logic:

import requests
from tenacity import retry, stop_after_attempt, wait_exponential

@retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=2, max=10))
def convert_file(input_path, target_format):
    with open(input_path, 'rb') as f:
        response = requests.post(
            'https://changethisfile.com/v1/convert',
            headers={'Authorization': f'Bearer {CTF_API_KEY}'},
            files={'file': f},
            data={'target': target_format},
            timeout=120
        )
    response.raise_for_status()
    return response.content

Rollback plan

Keep your CloudConvert API key active during the migration period. A safe rollback takes under 5 minutes:

1. Keep both integrations behind a feature flag or environment variable: CONVERTER=changethisfile vs CONVERTER=cloudconvert.
2. If ChangeThisFile returns errors for a specific format (e.g., a format in your pipeline that falls outside ChangeThisFile's ~1,000 routes), set CONVERTER=cloudconvert to revert immediately.
3. Run parallel for 48–72 hours if your volume allows it — call both APIs and compare outputs before switching traffic fully.
4. Cancel your CloudConvert subscription once you've confirmed 30 days of clean ChangeThisFile operation.

ChangeThisFile returns HTTP 400 with a JSON error body if the format pair is unsupported. Log these errors during the parallel-run period to catch any edge-case formats before full cutover.

Common migration questions

Does ChangeThisFile support all the same formats as CloudConvert?
No. ChangeThisFile covers roughly 1,000 conversion routes; CloudConvert's catalog is broader, particularly for CAD, EXR, HDR, and industry-specific formats. List every source→target pair in your existing jobs and check them before you commit. Keep CloudConvert for anything missing.

What happens when I hit my monthly quota?
The API returns HTTP 429 and stops converting until the next billing cycle. ChangeThisFile does not bill overage on paid plans, so a traffic spike becomes failed requests rather than a larger invoice. Size your plan for your peak month, and poll GET /v1/usage to watch conversions_this_month against monthly_limit.

How do I handle large files?
The free tier caps uploads at 25 MB. Paid plans raise it: 100 MB on Hobby, 500 MB on Startup, 2 GB on Scale, 5 GB on Growth. CloudConvert allows 1 GB on its free tier, so file size alone can be a reason to stay.

Can I keep using the CloudConvert SDK and just change the endpoint?
No. The SDK wraps an async job API; ChangeThisFile's is synchronous with a different shape. You will rewrite those calls, though the rewrite is shorter than the original (see the before/after above).

What's the timeout?
The conversion service allows 180 seconds for a single synchronous conversion. Set your HTTP client timeout above that. Most conversions finish in under 10 seconds; anything longer should go through the asynchronous /v1/jobs endpoint instead. Work that needs to run for hours is a reason to stay on CloudConvert.

Does ChangeThisFile have a staging environment?
No separate staging environment. The free tier (25 conversions/month) runs on the same infrastructure as production, which is enough to validate a format pair but not enough to load-test.

Read your CloudConvert dashboard's credit consumption before you change anything. If you are averaging close to 1 credit per conversion, this migration is a cost increase and the only thing you gain is a simpler integration. If you are averaging 3 or more - PDF-to-Office, big documents, long video - the flat per-conversion price is worth pricing out properly.

Either way, test before you commit: get a free API key (25 conversions a month, no card) and run your most common format pair through it. Compare the output files, not just the invoice.