Migrate from SerpApi: A Practical SearchCans Plan

Moving from SerpApi to SearchCans is an integration project, not a find-and-replace exercise. The safest path is to keep the existing provider available, add an adapter around the new contract, compare equivalent requests, and move traffic in stages. This page focuses on that migration sequence. For a provider-level comparison, see SearchCans vs SerpApi and Parallel Lanes.

Migration checklist

1. Inventory every SerpApi endpoint, engine, parameter, response field, and error path in production.
2. Define a normalized internal result model before changing the provider.
3. Implement the SearchCans adapter behind a feature flag.
4. Compare representative queries in shadow traffic.
5. Roll out by cohort and keep a rollback switch until the new path is stable.

What changes in the request contract

The current SearchCans SERP API uses a POST request to https://www.searchcans.com/api/v1/search. Authentication uses Authorization: Bearer YOUR_API_KEY. The request body uses t for the engine and s for the search query.

import requests

def searchcans_search(query: str, api_key: str) -> dict:
    response = requests.post(
        "https://www.searchcans.com/api/v1/search",
        headers={"Authorization": f"Bearer {api_key}"},
        json={
            "t": "google",
            "s": query,
            "country": "us",
            "language": "en",
            "p": 1,
            "d": 30000,
        },
        timeout=35,
    )
    response.raise_for_status()
    return response.json()

Do not pass the provider response directly through the application. Normalize fields such as title, link, position, snippet, and feature blocks into your own model. This isolates the rest of the product from future provider changes and makes a side-by-side test meaningful.

Build an adapter before shadow traffic

The adapter should own four jobs:

• Authentication and endpoint configuration.
• Request translation from your internal query model.
• Response normalization and validation.
• Error classification and retry policy.

Keep the SerpApi adapter and the SearchCans adapter behind the same interface. A feature flag can then choose the primary provider, while a shadow mode sends a carefully bounded copy of selected requests to the secondary path. Shadow traffic should protect customer latency and should not double every expensive workload by default.

Compare like with like

Use a fixed evaluation set that represents production intent. Include branded, local, multilingual, long-tail, and feature-heavy queries if those appear in your product. Compare:

Avoid claiming a universal accuracy or latency percentage from a small test. Record the workload, date, region, parameters, and sample size so the result can be reproduced.

Plan the SearchCans budget

SearchCans uses prepaid credits that are valid for 6 months. Successful standard Google and Bing searches cost 1 credit per request. The Reader API standard mode costs 2 credits. Failed or non-200 requests are not billed according to the current product policy.

The current plans list these Parallel Lane counts: Standard 2, Starter 5, Pro 37, and Ultimate 113. A lane is simultaneous request capacity, not a monthly request allowance. Eligible paid plans can add lanes together. Use your measured concurrency and credit use to choose a plan, then re-check the live pricing page before committing because pricing can change.

Roll out with a rollback path

Use a staged sequence:

Stage 1: Internal validation

Run the adapter against recorded, non-sensitive test cases. Validate parsing, timeouts, retry classification, and observability before exposing customer traffic.

Stage 2: Shadow traffic

Send a bounded sample to both providers. Compare normalized outputs and log disagreements. Do not treat disagreement as automatic failure; inspect whether a different result is actually harmful for the product’s intent.

Stage 3: Small production cohort

Route a small, measurable cohort to SearchCans. Watch successful responses, p95 latency, downstream parse errors, credits, and user-visible failures.

Stage 4: Expand and retire deliberately

Increase the cohort only when the previous stage meets its acceptance criteria. Keep the old adapter available until the rollback window closes, then remove it in a separate maintenance change.

Use Reader for selected URLs, not every result

If the application needs page text after search, deduplicate and rank URLs first. Then call POST https://www.searchcans.com/api/v1/url with t: "url" and s set to the target URL. Use mode: 1 for JavaScript-rendered pages, and begin with proxy: 0 before escalating to another tier.

This separation makes cost and failures visible: SERP discovery answers “which URLs matter?” and Reader answers “what does the selected page say?”

Frequently Asked Questions

Q: Is SearchCans a drop-in SerpApi replacement?

A: No. The endpoint, HTTP method, authentication, request fields, and response shape need an adapter and tests. Treat compatibility as an engineering task.

Q: How should I estimate migration savings?

A: Use your own request volume, successful-call mix, Reader usage, retries, and lane needs. Compare current provider spend with the current SearchCans credit and plan facts, then include migration and monitoring effort.

Q: Should I delete the old provider immediately after cutover?

A: No. Keep a reversible fallback through the agreed rollback window. Remove credentials and dead code later as a separate, reviewed change.

Conclusion

A careful SerpApi migration preserves product behavior while making the provider boundary explicit. Normalize the contract, compare real workload samples, use bounded shadow traffic, and roll out in cohorts. That process gives cost and reliability claims a traceable basis instead of turning a provider switch into a blind rewrite.