Control Plane API workflows: apps, billing, and webhooks

Control Plane integrations are easier to reason about when operations are grouped into workflows instead of treated as an alphabetical list of endpoints. The public API covers both seller-facing application and revenue activity and buyer-facing user, data, and proxy operations.

The public OpenAPI document remains authoritative for request and response shapes, while the interactive explorer presents it for human review. This page maps the resource groups into operating sequences.

Establish the account context

Authentication and profile operations establish who the caller is and which capabilities are available. Interactive sessions use the supported authentication and refresh flows. Approved service access can use account-level API keys where the contract permits it.

Profile operations expose account state and include a dedicated proxy-password rotation action. Rotation should be treated as a credential event: update dependent systems deliberately, avoid logging either value, and verify the new credential before removing the old operational path.

Manage seller applications

The Apps group lists, creates, reads, updates, and deletes application review records. A typical sequence is:

1. create the application record with the required product information;
2. read the returned resource and retain its identifier;
3. update the record as integration and review data changes;
4. use analytics and payout resources only within the account and application context defined by the API;
5. delete only when the product workflow confirms the record is no longer required.

The HTTP method is part of the contract. PUT and PATCH operations are not interchangeable; follow the request schema and documented semantics on the relevant operation page.

Operate managed users and data balances

Buyer accounts can list, create, read, update, and delete managed users. Additional operations change user data balance and rotate a managed user’s proxy password.

A balance-changing operation belongs in an auditable workflow. Capture the final request identifier, reconcile against the Data Transactions list, and avoid treating a client timeout as proof that no change occurred.

Credential rotation and balance changes should be separated from ordinary profile edits in UI permissions, operational alerts, and support procedures.

Read analytics as reporting data

Analytics endpoints cover overall activity, bandwidth revenue, qualified revenue and leads, domains, IPs, and request logs. They are reporting interfaces, not lifecycle callbacks.

Callers should preserve filter and time-range context alongside exported values. When a dashboard combines multiple analytics operations, display their retrieval time and handle partial failure explicitly instead of silently mixing fresh and stale panels.

Separate buyer invoices from seller payouts

Billing resources represent different directions of value:

Resource	Workflow
Pricing and quote	Evaluate a buyer data purchase before creation
Purchase invoice	Create and inspect the buyer-side purchase record
Payout quote	Evaluate a seller payout
Payout	Create, list, and inspect seller payment records

Do not infer final settlement from the success of a quote request. Use the returned resource and its documented state in subsequent operations.

Use targeting catalogs as controlled inputs

Locations endpoints provide countries, regions, cities, ZIP codes, and ASNs. Proxy Network endpoints provide servers and targeting options. Treat catalog values as API-owned identifiers rather than free-form labels stored permanently in application code.

Refresh catalogs at a suitable interval, validate saved selections when they are reused, and preserve the distinction between a location option and an available proxy server.

Design webhooks for retries and verification

Webhook operations list, create, read, update, delete, and test subscriptions. The test operation proves that the configured delivery path can receive an example; it does not replace production handling.

A webhook consumer should authenticate deliveries according to the approved contract, process duplicates safely, record delivery correlation without storing secrets, and return promptly before performing long-running work. Pair asynchronous events with read operations when the current resource state matters more than the event snapshot.

Use the Webhooks section in the API explorer for the exact subscription schema and test operation, then identify operations in runbooks by their stable operationId values.