How to Monitor SERP API Requests in Your App | SERPpost

SERP API monitoring starts in your application. Record the request context you sent, the HTTP and V1 response codes you received, and how the worker handled the result. For SERPpost V1, that means keeping a small log around calls to the Search and Reader endpoints. The account Dashboard shows credits, usage summaries, and Request Slots, but an application log is what lets you trace one job back to a query or URL.

This guide is for developers who need a practical record of their own SERPpost calls. It covers request logging, response checks, and the account signals that belong in a routine review. It does not present a latency benchmark, a cost forecast, or a managed alerting service.

What to record for each request

A useful record has enough context to reproduce a problem without storing more user input than the application needs. For a search call, keep the endpoint, result type, country, language, page number, depth, cache setting, elapsed time, HTTP status, V1 code, and returned request ID when one is present. For a Reader call, record the same execution fields plus the capture mode you selected.

Store a job ID from your own system. Treat raw queries and source URLs as application data: log them only when your retention and privacy rules allow it. A query length or a keyed hash is often enough to group recurring failures without keeping the original query in an application log.

Log a V1 search call in Python

The public V1 documentation uses an authenticated POST request to /api/v1/search. This example records the execution facts around that request. It checks the HTTP response and then the V1 response envelope before returning the data to the rest of the application.

import json
import logging
import os
import time

import requests

API_BASE = "https://serppost.com"
API_KEY = os.environ["SERPPOST_API_KEY"]
LOGGER = logging.getLogger("serppost_requests")


def call_v1(path, payload, job_id):
    started = time.perf_counter()
    response = requests.post(
        f"{API_BASE}{path}",
        headers={
            "Authorization": f"Bearer {API_KEY}",
            "Content-Type": "application/json",
        },
        json=payload,
        timeout=30,
    )
    elapsed_ms = round((time.perf_counter() - started) * 1000)

    try:
        envelope = response.json()
    except ValueError:
        envelope = {}

    record = {
        "event": "serppost_v1_request",
        "job_id": job_id,
        "endpoint": path,
        "result_type": payload.get("t"),
        "country": payload.get("country"),
        "language": payload.get("language"),
        "max_cache": payload.get("maxCache"),
        "http_status": response.status_code,
        "v1_code": envelope.get("code"),
        "request_id": envelope.get("data", {}).get("id"),
        "elapsed_ms": elapsed_ms,
    }
    LOGGER.info(json.dumps(record, sort_keys=True))

    response.raise_for_status()
    if envelope.get("code") != 0:
        raise RuntimeError(f"SERPpost V1 returned code={envelope.get('code')!r}")

    return envelope


search_result = call_v1(
    "/api/v1/search",
    {
        "s": "web to markdown api",
        "t": "google",
        "p": 1,
        "d": 20000,
        "country": "us",
        "language": "en",
        "maxCache": 0,
    },
    job_id="search-20260825-42",
)

The response shape can vary with the result type and the query. Parse the fields your workflow needs, rather than assuming that every search response carries the same result types. The V1 documentation is the current source for request parameters and exposed fields.

Add the same record around Reader

Reader starts with a public URL after your workflow has chosen a source to inspect. The current V1 request example uses /api/v1/url with t: "url". Reuse the same helper so search and capture calls are visible in one application log.

page_result = call_v1(
    "/api/v1/url",
    {
        "s": "https://example.com/article",
        "t": "url",
        "w": 3000,
        "d": 20000,
        "html": 1,
        "proxy": 0,
        "maxCache": 0,
    },
    job_id="capture-20260825-42",
)

The search request identifies a result set. The Reader request captures a selected public page or file. Keeping those calls separate in your records makes it easier to see whether a failed job came from search, source selection, or capture.

Decide what deserves an alert

The public V1 documentation describes requests and response fields. It does not publish a request-level history, an alerting service, or a service-level performance target for your application. Put the alert policy in the system that owns the job.

Start with conditions that your application can explain:

1. The HTTP request failed or timed out.
2. The V1 envelope returned a non-zero code.
3. A retry limit you chose was reached.
4. A required field for one of your downstream steps was absent.

Keep the alert payload small: job ID, endpoint, result type, market settings, response codes, and a link to your own log record are usually enough for triage. Set thresholds from your own traffic and user impact. A number copied from an example is not a production SLO.

Review account usage separately

Your application log answers what happened to an individual job. Your SERPpost Dashboard answers account-level questions: it displays available credits, permanent credits, usage summaries, and the number of Request Slots available to run live requests at once.

Review the Dashboard alongside your own logs when you change queue concurrency, add a new result type, or investigate a burst of retries. That gives you two different views of the same integration without treating either one as a substitute for the other.

A small operational checklist

1. Give each search or capture job an ID in your application.
2. Log the endpoint, result type, request settings, HTTP status, V1 code, and elapsed time.
3. Check the V1 envelope before using its data in downstream code.
4. Keep raw inputs only when your privacy and retention policy permits it.
5. Set retries and alerts in the worker that owns the job.
6. Use the API Playground to inspect a request before you promote a new integration path.
7. Check the Dashboard and pricing when changes to workload or concurrency affect account usage.

FAQ

Does the SERPpost Dashboard replace application logs?

No. The Dashboard is useful for account-level credits, usage summaries, and Request Slots. Your application should keep the request record it needs for job-level debugging, retries, and audit history.

Which response should my worker check first?

Check the HTTP response, parse the JSON envelope, and confirm code is 0 before using data. Then validate the fields that the next step in your application requires.

What should I log for a Reader request?

Record the endpoint, t, the capture options you selected, HTTP status, V1 code, elapsed time, job ID, and returned request ID when present. Store the source URL only if it fits your data-handling policy.

Does maxCache: 0 change how I should monitor a request?

It is part of the request context. Keep it in the log so a later investigation can distinguish a fresh request from a different cache choice. Choose production cache behavior deliberately for the workload you own.

Sources and review date

This guide was reviewed on August 25, 2026. The V1 endpoint shapes, request parameters, response envelope, Reader options, and Dashboard labels were checked against the current SERPpost V1 documentation and site source on that date. Validate current request and account details before shipping an integration.