1ClickIndexer REST API v1.4

1. API Overview

The 1ClickIndexer REST API enables developers, SEO agencies, websites, CMS plugins, and automation systems to submit URLs for indexing workflows and retrieve available indexing status information.

The API provides three primary endpoints:

1. POST /api/v1/index — Submit URLs for indexing.
2. GET /api/v1/status — Retrieve batch or individual URL status.
3. GET /api/v1/account — Retrieve account information, credit balances, API key metadata, and domain permissions.

The API supports two indexing modes: Instant Indexing and Regular Bulk Indexing.

1.1 Base URL

All API requests use the following base URL:

https://1clickindexer.com/api/v1

All requests must use HTTPS.

1.2 General API Limits

• Maximum URLs per submission request: 500.
• Minimum URLs per submission request: 1.
• Documented rate limit: 120 requests per minute per IP.
• Status queries: 0 credits.
• Account queries: 0 credits.
• URL log retention: 30 days, after which logs are automatically purged according to the documentation.

2. Indexing Modes

Each API key is bound to one of two indexing modes and routes requests to the corresponding credit pool.

2.3 Mode Comparison

These success rates and processing descriptions are taken from the supplied API documentation and have not been independently verified.

3. Authentication and Security

Every API request must include a valid API key using one of the supported authentication headers.

3.1 Bearer Token Authentication

Authorization: Bearer ui_live_YOUR_API_KEY
Content-Type: application/json

3.2 X-API-Key Authentication

X-API-Key: ui_live_YOUR_API_KEY
Content-Type: application/json

Replace ui_live_YOUR_API_KEY with the actual API key issued for your account.

Use one authentication method per request unless the provider specifies otherwise.

3.3 API Key Modes and Domain Permissions

The documentation describes the following API key configurations.

3.4 Security Requirements

• Store API keys in server-side environment variables.
• Never expose API keys in frontend JavaScript, public repositories, or customer-visible HTML.
• Use HTTPS for every request.
• Restrict API key access to authorized backend services.
• Log API errors without exposing secrets.
• Rotate compromised keys promptly.
• Keep provider API credentials separate from customer login credentials.

Example environment configuration:

INDEXER_API_BASE_URL=https://1clickindexer.com/api/v1
INDEXER_API_KEY=ui_live_YOUR_REAL_API_KEY

This is an example configuration. The API key must be supplied by the provider.

4. Endpoint 1 — Submit URLs for Indexing

This endpoint submits one or more URLs for indexing processing.

4.1 Request Headers

Authorization: Bearer ui_live_YOUR_API_KEY
Content-Type: application/json

Alternatively, use the X-API-Key authentication header.

4.2 Request Body

The documented request body contains the following fields:

Example Request

{
  "urls": [
    "https://example.com/blog/post-1",
    "https://example.com/blog/post-2",
    "https://example.com/product/item-1"
  ],
  "batchName": "October-SEO-Campaign"
}

Input Validation

Before submitting a request, the application should:

1. Confirm that urls is an array.
2. Require at least one URL.
3. Reject batches containing more than 500 URLs.
4. Validate URL syntax.
5. Check domain permissions when applicable.
6. Confirm that the account has sufficient credits.
7. Avoid automatically resubmitting the same request after an ambiguous timeout.

The documentation identifies empty URL arrays, batches exceeding 500 URLs, and invalid URL formats as potential 400 Bad Request errors.

The provider's exact URL normalization, duplicate detection, and batchName validation rules are not specified.

4.3 cURL Example

curl -X POST \
  "https://1clickindexer.com/api/v1/index" \
  -H "Authorization: Bearer ui_live_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "urls": [
      "https://example.com/blog/post-1",
      "https://example.com/blog/post-2"
    ],
    "batchName": "October-Campaign"
  }'

4.4 Successful Response

The supplied documentation provides the following example response structure:

{
  "success": true,
  "batchId": "batch-api-1789082001",
  "mode": "INSTANT",
  "submitted": 2,
  "balanceRemaining": 498,
  "estimatedSuccessRate": "90% - 95%",
  "upstreamStatus": "DISPATCHED"
}

Response Field Definitions

The values above are illustrative documentation examples, not live account data.

A successful API response confirms request acceptance or processing at the API layer. It does not guarantee that Google has indexed every URL.

4.5 Credit Consumption

The documentation specifies one credit per valid URL.

For example, if 100 valid URLs are submitted, the expected credit requirement is 100 credits.

Before implementation, confirm whether credits are deducted at request acceptance, individual URL validation, or another processing stage. The supplied documentation does not fully define billing behavior for partially accepted batches or failed upstream requests.

4.6 Batch Processing

For submissions larger than 500 URLs, divide the URLs into batches.

Example:

• 100 URLs: one request.
• 500 URLs: one request.
• 1,000 URLs: two requests containing 500 URLs each.

Store each returned batchId separately so that each batch can be monitored independently.

4.7 Duplicate Requests and Timeouts

If a request times out, the client may not know whether the server accepted it.

Recommended behavior:

1. Record the request timestamp and submitted URLs.
2. Record the returned batchId whenever a response is received.
3. Use documented status lookup options where applicable.
4. Confirm whether the provider supports idempotency keys or duplicate detection.
5. Avoid automatically resubmitting ambiguous requests until duplicate handling is understood.

Idempotency support is not documented in the supplied PDF.

5. Endpoint 2 — Check Batch or URL Status

The endpoint retrieves status information for a batch or an individual URL.

According to the documentation, status queries consume zero credits.

5.1 Method A — Query by Batch ID

GET https://1clickindexer.com/api/v1/status?batchId=batch-api-1789082001

Input

Use this method to retrieve information about a previously submitted batch.

5.2 Method B — Query by URL

GET https://1clickindexer.com/api/v1/status?url=https%3A%2F%2Fexample.com%2Fblog%2Fpost-1

Input

URL-encode query parameter values where necessary to ensure special characters are transmitted correctly.

5.3 Status Response Structure

The documentation describes a response containing success, batch, and records.

Example structure:

{
  "success": true,
  "batch": {
    "id": "batch-api-1789082001",
    "mode": "INSTANT",
    "totalUrls": 2,
    "indexedCount": 1,
    "crawledCount": 2,
    "estimatedSuccessRate": "90% - 95%"
  },
  "records": []
}

This is an illustrative structure based on the documented fields. The exact records schema and all possible status values are not fully specified in the supplied PDF.

Response Fields

5.4 Dashboard Integration

The application may display:

• Batch name.
• Batch ID.
• Number of submitted URLs.
• Number of crawled URLs.
• Number of indexed URLs.
• Indexing mode.
• Last status-check time.
• Available job status information.

Map provider status values to customer-facing labels only after confirming the actual response schema.

Crawled and indexed counts must be displayed separately. A URL being crawled does not necessarily mean it has been indexed by a search engine.

5.5 Status Polling

The supplied documentation does not specify a mandatory polling interval.

Recommended implementation:

1. Schedule status checks for active batches.
2. Use reasonable intervals instead of repeatedly polling every few seconds.
3. Stop frequent polling after a batch reaches a confirmed terminal state.
4. Respect the documented limit of 120 requests per minute per IP.
5. Avoid making separate status requests for every URL when a batch query provides sufficient information.

6. Endpoint 3 — Account Information and Credit Balances

This endpoint retrieves account and API key information.

According to the supplied documentation, account queries consume zero credits.

6.1 Request Example

curl -X GET \
  "https://1clickindexer.com/api/v1/account" \
  -H "Authorization: Bearer ui_live_YOUR_API_KEY"

No request body is specified in the documentation.

6.2 Documented Account Information

The exact nesting and complete JSON schema of all account fields are not fully specified in the supplied PDF.

6.3 Account Dashboard Use Cases

Use this endpoint to:

1. Display the provider's available Instant and Regular credits.
2. Check the API key's configured mode.
3. Monitor account status.
4. Review available domain permissions.
5. Support low-credit alerts.
6. Assist administrators with API monitoring and troubleshooting.

Provider credits must remain separate from customer credits sold through the 1ClickIndexer platform.

7. Error Codes and Error Handling

The supplied documentation lists the following HTTP status codes.

The provider's exact error-response JSON schema is not specified in the supplied documentation.

7.1 Recommended Application-Level Error Format

The following is a proposed internal response format for your own application, not a documented provider response:

{
  "success": false,
  "code": "PROVIDER_CREDITS_LOW",
  "message": "Insufficient provider credits.",
  "retryable": false
}

Use consistent internal error codes so that the frontend can display understandable messages without exposing internal credentials or server details.

7.2 Error Handling Rules

• Do not automatically retry 401 or 403 without correcting the underlying issue.
• Validate and correct requests that return 400.
• Check provider credit balances after 402.
• Treat network timeouts as ambiguous until request acceptance is known.
• Retry transient server errors only with controlled backoff and a duplicate-submission strategy.
• Log errors securely for troubleshooting.

Retry behavior for HTTP 429 and 5xx responses is not specified in the supplied PDF and should be confirmed during live API testing.

8. Rate Limits and Log Retention

The documentation specifies:

• Rate limit: 120 requests per minute per IP.
• Maximum batch size: 500 URLs per submission.
• URL log retention: 30 days.
• Status queries: 0 credits.
• Account queries: 0 credits.

Implement rate limiting and a job queue in your own backend so that multiple customers do not overload the API.

If your platform needs job history beyond 30 days, maintain the required records in your own database. Do not assume provider-side logs remain available after the documented retention period.

9. Recommended Integration Architecture

The following architecture is recommended for a commercial platform built around the API.

9.1 Customer Workflow

1. A customer signs in to 1ClickIndexer.
2. The customer selects an eligible indexing plan.
3. The customer submits one or more URLs.
4. The backend validates the URLs and customer credit balance.
5. The backend sends the request to the provider API.
6. The backend stores the response and provider batch ID.
7. The dashboard displays the accepted submission and available status information.
8. The backend queries the status endpoint according to a controlled schedule.
9. The customer dashboard updates the available job information.
10. The internal credit ledger records the transaction.

9.2 Backend Components

10. Recommended Database Structure

The following schema is a suggested implementation design, not a schema required by the provider.

10.1 Users Table

10.2 Indexing Jobs Table

10.3 Credit Transactions Table

Use database transactions or equivalent atomic operations to prevent duplicate deductions and race conditions when multiple submissions happen simultaneously.

11. Customer Credits vs. Provider Credits

These are two different balances and must not be treated as interchangeable.

Your backend must manage customer credit allocation independently from the provider's balance.

Recommended Billing Flow

1. Validate the customer's available balance.
2. Create a pending submission record.
3. Submit the URL batch to the provider.
4. Store the response and batch ID.
5. Finalize the customer credit transaction according to the agreed billing policy.
6. Handle failed requests and refunds through an auditable ledger.

Do not deduct customer credits solely because a request was attempted. Define how accepted, partially accepted, and failed requests are billed.

Confirm provider billing behavior before implementing automatic refunds or credit adjustments.

12. Node.js Integration Example

The following example demonstrates a basic backend client using Node.js and fetch.

It includes basic input validation and HTTP error handling.

const API_BASE_URL =
  process.env.INDEXER_API_BASE_URL ||
  "https://1clickindexer.com/api/v1";

const API_KEY = process.env.INDEXER_API_KEY;

async function submitUrls(urls, batchName) {
  if (!API_KEY) {
    throw new Error("Indexer API key is not configured.");
  }

  if (!Array.isArray(urls) || urls.length < 1 || urls.length > 500) {
    throw new Error("Submit between 1 and 500 URLs.");
  }

  for (const value of urls) {
    let parsed;

    try {
      parsed = new URL(value);
    } catch {
      throw new Error(`Invalid URL: ${value}`);
    }

    if (!["http:", "https:"].includes(parsed.protocol)) {
      throw new Error("Only HTTP and HTTPS URLs are supported.");
    }
  }

  const response = await fetch(`${API_BASE_URL}/index`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${API_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      urls,
      ...(batchName ? { batchName } : {})
    })
  });

  const data = await response.json();

  if (!response.ok) {
    const error = new Error(
      `Indexer API returned HTTP ${response.status}`
    );

    error.statusCode = response.status;
    error.response = data;

    throw error;
  }

  return data;
}

Example Usage

async function main() {
  const result = await submitUrls(
    [
      "https://example.com/page-1",
      "https://example.com/page-2"
    ],
    "October-Campaign"
  );

  console.log("Batch ID:", result.batchId);
  console.log("Submitted:", result.submitted);
  console.log("Mode:", result.mode);
}

main().catch(console.error);

This is a basic integration example. A production implementation should also handle timeouts, malformed responses, transient errors, idempotency, and secure logging.

13. Python Integration Example

import os
import requests

API_BASE_URL = os.getenv(
    "INDEXER_API_BASE_URL",
    "https://1clickindexer.com/api/v1"
)

API_KEY = os.environ["INDEXER_API_KEY"]


def submit_urls(urls, batch_name=None):
    if not 1 <= len(urls) <= 500:
        raise ValueError(
            "Submit between 1 and 500 URLs."
        )

    payload = {"urls": urls}

    if batch_name:
        payload["batchName"] = batch_name

    response = requests.post(
        f"{API_BASE_URL}/index",
        headers={
            "Authorization": f"Bearer {API_KEY}",
            "Content-Type": "application/json",
        },
        json=payload,
        timeout=30,
    )

    response.raise_for_status()
    return response.json()


result = submit_urls(
    ["https://example.com/page-1"],
    "October-Campaign"
)

print("Batch ID:", result.get("batchId"))
print("Submitted:", result.get("submitted"))

The example uses the documented submission endpoint. Test it with valid credentials before deploying it to production.

14. Important Items to Confirm Before Production

The supplied PDF does not fully specify the following details. Confirm them with the provider or through authorized live API testing.

1. How API keys are generated, revoked, and rotated.
2. The exact JSON schemas for every endpoint.
3. All possible upstream and individual URL status values.
4. Whether batchName is optional and its validation rules.
5. Whether the API supports idempotency keys or duplicate detection.
6. Whether webhooks are available for status notifications.
7. Exact credit deduction rules for partially accepted batches and failed upstream requests.
8. Whether MULTI_DOMAIN access requires manual approval.
9. API pricing, credit purchase methods, and reseller permissions.
10. Whether lower-tier Regular plans can use the Regular API.
11. Retry behavior for rate-limit and server errors.
12. Whether status information remains available after provider logs are purged.

Do not invent unsupported request fields such as callbackUrl, webhookUrl, priority, dripFeedDays, or custom mode parameters unless the provider explicitly documents them.

15. Final Developer Checklist

Before launching the integration: