DataPacket GraphQL API

November 2025: Provisioning API added

New types and fields

• Added provisioningConfigurations query to retrieve a list of server configurations that match your requirements.
• Added provisionServer mutation to provision a new server with the selected configuration.
• Added operatingSystems query to retrieve a list of available operating systems that can be installed on the provisioned servers.
• Added type, scope and bandwidth fields to the TrafficPlan type.
• Added cores and threads fields to the Cpu type.
• Deprecated the count field in the Cpu, Ram and Hdd types; resource count is now derived from the length of their respective arrays.
• Replaced the Os type and the os field in the System type with th new OperatingSystem type and operatingSystem field.
• Replaced the SSD enum member of the StorageType enum with SATA_SSD.
• Added the LocationIdentifier enum and the new identifier field to the Location type.
• Added locations query to retrieve a list of all locations.
• Replaced the deprecated hdds field in Hardware with the new storage field; the Hdd type is now deprecated.
• Added the Region enum and applied it to the region field of the Location type.
• Removed the instantDeliveryServer and instantDeliveryServers queries in favour of the new provisioningConfigurations query.

September 2025: Post-install scripts management

New types and fields

Introduced new types and fields, including the postInstallScripts query for listing scripts, plus mutations for managing them: createPostInstallScript to add a new one, updatePostInstallScript to edit, and deletePostInstallScript to remove.

June 2025: Traffic per server field

New types and fields

• Added perServer field to the Traffic type in the traffic query to provide traffic statistics for each server.

May 2025: Link configuration API added

New types and fields

• Added configureServerLinks mutation to configure link aggregation on ports.
• Added serverLinksConfigurationTask query to retrieve the current status of the link configuration task.
• Added hasLinkAggregation field to the Server type to retrieve the current link aggregation status.

July 2024: servers query changes

Field changes

• The status field has been deprecated and replaced with a new field called statusV2. The statusV2 field provides a more accurate representation of the server’s production status.

Input argument changes

• The field changes are also reflected in the input arguments. The serverStatus_in filter has been deprecated, and it is recommended to use the new serverStatusV2_in filter for filtering based on the server’s status.

• The tags_each input argument has been renamed to tag_value. The old tags_each argument name has been deprecated.

• A new argument called tag_key has been introduced to filter based on tag keys.

---

To get an introduction to GraphQL, you can use the official documentation, or learn with the How to GraphQL tutorials.

GraphQL requests can be sent via HTTP POST or HTTP GET requests. POST requests sent with the Content-Type header application/json must have a POST body in the following JSON format:

{
  "query": "...",
  "variables": { "myVariable": "someValue", ... }
}

GET requests must be sent in the following format. The query and variables are sent as URL-encoded query parameters in the URL.

https://api.datapacket.com/v0/graphql?query={...}&variables={...}

In either request method (POST or GET), only a query is required. variables is only required if the query contains GraphQL variables.

There are many GraphQL clients available for different platforms.

The easiest way to start is to use our GraphQL playground. Alternatively, you can use a simple HTTP client like cURL. For example, the following command will fetch your account information:

curl -X POST 'https://api.datapacket.com/v0/graphql' \
  -H 'Authorization: Bearer your-api-key' \
  -H 'Content-Type: application/json' \
  -d '{"query":"query account { account { name email } }"}'

---

There are two types of GraphQL requests: queries and mutations.

Queries are read-only and do not change the system's state. Only requested query fields are returned in the response. Fields ending with ! are non-nullable. If the field is not available, the query will fail. The response is a JSON object and the requested data is returned in the data field.

Mutations are used to change data and must be sent via POST request.

We recommend using our GraphQL playground to explore the queries and mutations provided by the DataPacket API.

Input variables

Use variables to pass arguments to a query or mutation. Define variables in the request body and reference them in the query or mutation. Fields suffixed with ! are required.

For example, the performServerPowerAction mutation requires the server and status fields. To turn the DP-12345 server on, you can use the following query:

curl -X POST 'https://api.datapacket.com/v0/graphql' \
  -H 'Authorization: Bearer your-api-key' \
  -H 'Content-Type: application/json' \
  -d '{
        "query":"mutation performServerPowerAction($input: PerformServerPowerActionInput!) { performServerPowerAction(input: $input) { server { name } } }",
        "variables": { "input": { "server": { "name": "DP-12345" }, "action": "ON" } }
      }'

The logical relation between input parameters for filtering is always AND. When specifying more than one value for a filter parameter ending with *_in, the values in the array have the OR relation.

For example, to get IPMI IP addresses of all your servers in London or Amsterdam with power status ON, you would call the following query:

 curl -X POST 'https://api.datapacket.com/v0/graphql' \
  -H 'Authorization: Bearer your-api-key' \
  -H 'Content-Type: application/json' \
  -d '{
       "query":"query servers($input: PaginatedServersInput) { servers(input: $input) { entriesTotalCount currentPageIndex entries { name network { ipmi { ip } } } } }",
       "variables": { "input": { "pageIndex": 0, "pageSize": 20, "filter": { "location_in": ["London", "Amsterdam"], "powerStatus_in": ["ON"] } } }
      }'

---

Queries and mutations can return errors. If an error occurs, the response will contain an errors field with a list of errors. Each error has a message field with a human-readable error message and a code field with an error code. List of error codes can be found in the Error section.

Errors typically return HTTP status code 200. Malformed requests will also return an errors field along with HTTP status code 400.

GraphQL errors are returned in the following format:

{
  "errors": [
    {
      "message": "Error message",
      "extensions": {
        "code": "ERROR_CODE"
      }
    }
  ]
}

---

All results are paginated. You can specify the number of results per page and the page number using pageSize and pageIndex input variables. The maximum number of results per page is 50. The total number of results is returned in the entriesTotalCount field.

---

This section explains how to provision a new server using the DataPacket GraphQL API. The process involves filtering available configurations, selecting a suitable configuration, and then provisioning a server with your chosen options.

• Fetch available configurations
• Select the configuration
• Provision the server
• Billing period
  • Daily billing
  • Monthly billing
• Traffic plan

1. Fetch available configurations

Use the provisioningConfigurations query to retrieve a list of server configurations that match your requirements. You can filter configurations by region, CPU, memory, storage, GPU, price, and other parameters.

What is a configuration?

A configuration represents a specific, available server setup that matches a set of hardware and location criteria. Each configuration is a concrete offering that you can immediately provision as a server.

It is identified by a unique configurationId and includes information such as:

• CPU(s): Model, number of cores, threads, and count.
• Memory: Total RAM available.
• Storage: Types (e.g., SATA_SSD, NVME, HDD) and sizes of storage devices.
• GPU(s): Model and memory (if available).
• Uplink: Network port capacities.
• Pricing: Monthly and daily price, with currency.
• Location: Data center name, region, and short code.
• Stock count: Number of servers of this configuration currently available.

Example query:

query ProvisioningConfigurations($input: ProvisioningConfigurationsInput!) {
  provisioningConfigurations(input: $input) {
    configurationId
    cpus {
      name
      cores
    }
    memory
    storage {
      size
      type
    }
    gpus {
      name
      memory
    }
    uplink {
      ports {
        capacity
      }
    }
    monthlyHwPrice  {
      amount
      currency
    }
    dailyHwPrice {
      amount
      currency
    }
    location {
      name
      identifier
    }
    stockCount
  }
}

Example variables:

{
  "input": {
    "region_in": ["EU", "NA"],
    "cpuCores": { "min": 128 },
    "cpuCount": { "min": 2, "max": 2 },
    "memory": { "min": 256 },
  }
}

Adjust the filters as needed for your use case. The query supports a wide range of filtering options:

• Location filters: Use locationIdentifier_in or region_in to specify data center locations or geographical regions. All available locations and regions are listed in the LocationIdentifier enum and Region enum.

• CPU filters: Filter by cpuCores, cpuThreads, or specific cpuName_in values

• Memory filters: Set minimum/maximum RAM requirements with memory.min and memory.max (in GB)

• GPU filters: Filter configurations with specific GPU models using gpuCount and gpuMemory

• Price filters: Limit results by price range with monthlyHwPriceAmount.max and dailyHwPriceAmount.max

• Storage filters: Use storageRequirements to define specific storage criteria. This array allows you to set multiple storage conditions that server configurations must satisfy. Each entry in the array filters a subset of drives by type (if specified) and applies size and quantity constraints. A configuration is included in results only when it meets all specified storage requirements.

  Full format:

  • type_in: Array of storage types (SATA_SSD, NVME, HDD)
  • totalSize: Object with min and max values for total size in GB
  • count: Object with min and max values for number of drives

   

  Examples

  This finds configurations with at least 4 NVMe drives totaling 12TB or more:

  {
    "input": {
      "storageRequirements": [
        {
          "type_in": ["NVME"],
          "count": { "min": 4 },
          "totalSize": { "min": 12000 }
        }
      ]
    }
  }
  

  This finds configurations with 2 SSDs for system AND total HDD storage of at least 100TB:

  {
    "input": {
      "storageRequirements": [
        {
          "type_in": ["SATA_SSD", "NVME"],
          "count": { "min": 2, "max": 2 }
        },
        {
          "type_in": ["HDD"],
          "totalSize": { "min": 100000 }
        }
      ]
    }
  }
  

  This finds configurations with exactly 2 NVMe drives. The first condition specifies the drive type and count, and the second condition limits the total count of drives to 2:

  {
    "input": {
      "storageRequirements": [
        {
          "type_in": ["NVME"],
          "count": { "min": 2, "max": 2 }
        },
        {
          "count": { "min": 2, "max": 2 }
        }
      ]
    }
  }
  

   

You can combine multiple filters to narrow down results precisely. For example, you might want servers with at least 32 cores, 64GB RAM, and at least 2TB of SSD storage in either Amsterdam, Frankfurt or Paris.

  {
    "cpuCores": { "min": 32 },
    "memory": { "min": 64 },
    "storageRequirements": [
      {
        "type_in": ["NVME", "SATA_SSD"],
        "totalSize": { "min": 2000 }
      }
    ],
    "locationIdentifier_in": [ "AMSTERDAM", "FRANKFURT", "PARIS"]
  }

2. Select a configuration

After receiving the filtered configurations, select the one that best matches your needs.

Results are sorted by price, with the lowest priced configurations first, making it easy to find the most cost-effective option that meets your requirements.

Each configuration has a unique configurationId that you'll need for provisioning. The configurationId is a stable identifier that guarantees the exact hardware specifications, network capacity, and location you selected.

If you need to provision multiple identical servers in the same location, verify that there is sufficient stock to meet your requirements.

3. Provision the server

Use the provisionServer mutation to provision a new server with the selected configuration. You will need to provide the configurationId, desired billing period, operating system image, and optionally SSH keys.

The operating system will be installed on a RAID 1 volume across two drives. Any additional drives will remain unpartitioned for you to configure as needed.

Example mutation:

mutation ProvisionServer($input: ProvisionServerInput!) {
  provisionServer(input: $input) {
    server {
      name
      statusV2
      network {
        ipAddresses {
          isPrimary
          isBgpPrefix
          type
          netMask
          gateway
          network
          broadcast
          ip
          cidr
        }
        ipmi {
          ip
          username
        }
      }
    }
  }
}

Example variables:

{
  "input": {
    "configurationId": "your-selected-configuration-id",
    "billingPeriod": "MONTHLY",
    "osImageId": "your-os-image-id",
    "sshKeyNames": ["your-ssh-key-name"]
  }
}

• configurationId: The ID of the configuration you selected from the provisioningConfigurations query. This uniquely identifies the hardware configuration you want to provision.
• billingPeriod: The desired billing period (e.g., "MONTHLY" or "DAILY"). See Billing period for more information.
• osImageId: The ID of the operating system image to install. You can get this ID from the operatingSystems query, which returns a list of all available operating systems with their respective IDs. The No OS - Self installation via KVM/IPMI option is also available.
• sshKeyNames: An array of SSH key names to authorize for access. You can add SSH keys in the client panel before provisioning a server.

The provisionServer mutation is synchronous and either returns a newly provisioned server or an error. Returned server object contains the server's details.

Server provisioning status

When you provision a server using the provisionServer mutation, the server will initially be in one of two states:

1. PROVISIONING – The server is being set up and configured according to your specifications. This includes hardware allocation, operating system installation, and network configuration. During this state, the server is not yet accessible.

2. WAITING – The server is waiting for initial payment confirmation. This status typically appears when there are billing-related requirements that need to be fulfilled before provisioning can proceed (eg. subscription payment is pending).

Once the provisioning process completes successfully, the server status will change to ACTIVE, indicating that the server is fully operational and ready for use. At this point, you can access the server using the SSH keys you provided during provisioning. You will receive an email notification once the server is ready.

You can monitor the server's status by querying the statusV2 field of the server object. It's recommended to implement a polling mechanism that periodically checks the server status until it reaches the ACTIVE state before attempting to use the server.

Server provisioning errors

If the provisioning fails for any reason (such as insufficient resources, invalid configuration parameters, or system errors), the API will return an appropriate error message explaining the issue. You should implement proper error handling to catch and respond to these potential failures.

Server provisioning best practices

Do not forget to query the specific fields you're interested in when making the request. For example, if you need the server's name, IP address, and IPMI details, make sure to include these fields in your mutation. This ensures you have all the necessary information for subsequent requests without having to make additional API calls.

To provision multiple servers, you'll need to call the provisionServer mutation multiple times, once for each server you want to provision.

For automated deployments, you can implement a loop in your client code that:

1. Calls the mutation for each server configuration
2. Handles success/failure for each individual server
3. Tracks the overall provisioning status

When provisioning multiple servers, consider implementing retry logic with appropriate backoff periods to handle temporary failures.

Billing period

The API supports two billing periods for server provisioning. You can specify your preferred billing period using the billingPeriod parameter in the provisionServer mutation.

Daily billing - DAILY

• Billing is calculated daily based on UTC calendar days, with charges for each day processed at the start of the next UTC day
• The price consists of two components:
  • Hardware price: Cost of the physical server resources as defined by the configuration
  • Traffic price: Cost based on the amount of data transferred, calculated per TB (terabyte) of usage – see Traffic pricing by region
• Provides maximum flexibility for short-term needs
• Can be terminated at any time with billing stopping at the end of the current day
• Ideal for temporary workloads, testing, or when you need servers for an uncertain duration
• Generally has a higher per-day cost compared to monthly billing
• Requires a minimum DataPacket account balance of $100 to activate, with daily charges automatically deducted from your credit
• Selected trusted accounts may qualify for post-paid billing, allowing daily server charges to be accumulated and paid at the end of the month instead of requiring pre-funded credit

Traffic pricing by region

Region	Price per TB
EU	$3.00
NA	$3.50
APAC	$10.00
Australia	$25.00
Africa	$15.00
LATAM	$10.00
Tel Aviv	$12.00
Istanbul	$6.00
Seoul	$30.00
Fujairah	$30.00

 

These prices apply to daily billing periods. When calculating your total server cost, remember to factor in both the hardware cost and the expected traffic usage based on these regional rates.

Monthly billing - MONTHLY

• Servers are prepaid for an entire month
• Offers a significant discount compared to the equivalent daily rate
• Early termination is possible, but you will still be charged for the full month
• Best for production workloads, long-running services, or any scenario where you know you'll need the server for at least a month

When choosing between billing periods, consider your expected usage duration and budget constraints. For short-term needs (less than 2-3 weeks), daily billing might be more economical despite the higher per-day rate. For longer-term usage, the monthly discount typically makes the prepaid option more cost-effective.

Traffic plan

When provisioning a MONTHLY server, a traffic plan is automatically assigned based on the following logic:

1. Pooled Traffic Plan: If a pooled traffic plan is available in the region where you're provisioning the server, it will be selected automatically. Pooled traffic plans allow you to share bandwidth across multiple servers, which can be more cost-effective for deployments with varying traffic patterns.

2. Default Traffic Plan: If no pooled traffic plan is available in the region, the system will use your account's default traffic plan. This default plan can be pre-selected and configured in the client panel under your account billing settings.

This automatic selection ensures that your servers always have network connectivity without requiring you to explicitly specify a traffic plan during provisioning. However, you can always change the traffic plan after the server has been provisioned if your bandwidth needs change.