REST API

Infrastructure as an API, with predictable resource lifecycles.

The API model is designed around explicit resources, idempotent changes and structured responses so infrastructure automation can be reviewed, repeated and audited.

TWELVE YEARS OF INFRASTRUCTURE OPERATIONS · API-FIRST CONTROL · ENGINEERED FOR PRODUCTION

BITACTIVE / REST APILIVE ARCHITECTURE VIEW
POST /v1/edge-services{"name": "global-delivery","protocol": "http3","shield": true}RESOURCE201 CREATEDSTATEREADY / ACTIVE
POST → RESOURCE → EVENT → STATEOBSERVE
RESTresource model
JSONrequest / response
Idempotentchange semantics
VersionedAPI lifecycle

VISUAL / SERVICE MODEL

See the architecture before reading the detail.

This view summarizes the service boundary, decision points and operational signals for Rest Api.

System topologyLOGICAL VIEW / NOT TO SCALE
POST /v1/edge-services{"name": "global-delivery","protocol": "http3","shield": true}RESOURCE201 CREATEDSTATEREADY / ACTIVE
The diagram represents the logical request or control path. Exact placement, capacity and failure-domain selection are defined during architecture review.
Operational signalsCONTROL PLANE
POST
CREATE
82%
RESOURCE
RETURN
67%
EVENT
EMIT
91%
STATE
OBSERVE
74%
Visual status indicators are conceptual UI examples and do not expose customer data.
01 / POSTCREATE

Traffic or control enters a defined service boundary.

02 / RESOURCERETURN

Policy and placement are evaluated against current state.

03 / EVENTEMIT

The workload is processed by the appropriate infrastructure layer.

04 / STATEOBSERVE

Telemetry is preserved so the path can be explained operationally.

Authentication

Use scoped API credentials and keep automation identities separate from interactive administration.

BitActive keeps the operational model explicit: authentication scope, resource identity, intended state and error handling should be visible to automation rather than inferred from an interactive control panel. This makes changes easier to review and reduces the chance that an emergency fix becomes undocumented infrastructure.

Idempotent workflows

Create and update operations are structured so repeated automation does not silently fork configuration.

BitActive keeps the operational model explicit: authentication scope, resource identity, intended state and error handling should be visible to automation rather than inferred from an interactive control panel. This makes changes easier to review and reduces the chance that an emergency fix becomes undocumented infrastructure.

Versioned configuration

Changes to delivery, network and compute resources can be tracked as deliberate state transitions.

BitActive keeps the operational model explicit: authentication scope, resource identity, intended state and error handling should be visible to automation rather than inferred from an interactive control panel. This makes changes easier to review and reduces the chance that an emergency fix becomes undocumented infrastructure.

Errors with context

Responses distinguish validation, authorization, capacity and dependency failures so automation can react safely.

BitActive keeps the operational model explicit: authentication scope, resource identity, intended state and error handling should be visible to automation rather than inferred from an interactive control panel. This makes changes easier to review and reduces the chance that an emergency fix becomes undocumented infrastructure.

Example

The following example is illustrative and shows the intended configuration style. Resource names and exact schema may vary by service version.

curl -X POST "https://api.bitactive.com/v1/edge-services" \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "media-edge",
    "regions": ["eu-west", "us-east"],
    "origin_shield": true,
    "protocol": "http3"
  }' 
Production credentials, invitation details and service-specific endpoints are provided only within an active client engagement.

Operational notes

BitActive has evolved its infrastructure operating model over twelve years. The current design consolidates documentation, API concepts and infrastructure-as-code workflows around the same resource vocabulary so teams do not need to translate between unrelated provisioning and operational systems.

Public documentation intentionally describes architecture and behaviour without exposing customer information, private topology, account data or contractual details. Formal service documentation is supplied directly before an engagement is signed.

Discuss the architecture.

BitActive works with referred clients on premium infrastructure engagements. Start with the workload, traffic profile and operational requirements.

Request an introduction