Databases / Orders

Database orders

Creating a database places an order that is paid before anything is built. Follow it from payment to a running database, and know what each status and failure means.

Paid first, then built

A database is paid for before it is built, exactly like a virtual machine. POST /databases does not build anything itself: it records an order and answers 202 Accepted with it. Then, in the background:

The order takes the upfront payment, amount_minor: from your credit if there is enough, otherwise from your organization's default card.
Once paid, the database is built. The order's operation_id is set, and you can follow that operation too.
The order ends provisioned when the database is running.

The amount is what a VM in a VPC on the same plan costs, with the data disk at the size you chose. See pricing.

Place one

Terminal

$ curl https://api.pantechdynamics.com/public/v1/databases \    -H "Authorization: Bearer $PANTECH_API_KEY" \    -H "Idempotency-Key: $(uuidgen)" \    -H "Content-Type: application/json" \    -d '{"name": "orders-db", "engine": "postgresql", "version": "18",         "plan_slug": "starter", "zone_id": "af-abj-2", "subnet_id": "snet_…"}'

JSON

{
  "order_id": "ord_…",
  "database_id": "db_…",
  "resource_id": "db_…",
  "status": "awaiting_payment",
  "operation_id": null,
  "failure_code": null,
  "amount_minor": 1059200,
  "currency": "NGN",
  "admin_username": "dbadmin",
  "password_returned": true,
  "password": "q8Vn3TzK1mXw7RbLc4Hs9JdP2fYa6GeU"
}

amount_minor is in kobo (or cents for USD): 1059200 is NGN 10,592.00. database_id is the id the database will have; you can read it straight away. The response's Location header is the order's URL. If a password was generated, it is in this response and nowhere else: see passwords.

If there is not enough credit and no card to fall back on, the request itself is refused with 402 INSUFFICIENT_CREDIT and no order is made.

Follow it

Terminal

$ curl https://api.pantechdynamics.com/public/v1/database-orders/ord_… \    -H "Authorization: Bearer $PANTECH_API_KEY"

Poll every few seconds until status is final:

`status`	Meaning	Final?
`awaiting_payment`	Taking the payment, from credit or else your default card
`paid`	Paid; about to be built
`provisioning`	Being built. `operation_id` is set
`provisioned`	Built. Read the database for its hostname	Yes
`payment_failed`	Not paid, so nothing was built	Yes
`failed`	Paid but not built. The payment goes back to your credit	Yes

A small script that waits:

Shell

order=ord_…
while :; do
  status=$(curl -s "https://api.pantechdynamics.com/public/v1/database-orders/$order" \
    -H "Authorization: Bearer $PANTECH_API_KEY" | jq -r .status)
  echo "$status"
  case "$status" in provisioned|failed|payment_failed) break ;; esac
  sleep 5
done

provisioned means the build has finished. Then read the database, and wait for observed_state running and a hostname before you connect.

An unpaid order expires after an hour

An order still awaiting_payment one hour after it was placed ends payment_failed with failure_code payment_expired, and nothing is built. That usually means a card payment that needed you to act and never completed. Top up your credit or fix your card, then create the database again with a new Idempotency-Key.

Why an order failed

failure_code says why an order ended payment_failed or failed:

`failure_code`	Status	What happened	What to do
`insufficient_credit`	`payment_failed`	Not enough credit, and no card to fall back on	Add funds and order again
`card_declined`	`payment_failed`	Your default card was declined	Use another card, or add credit
`payment_expired`	`payment_failed`	Still unpaid an hour after it was placed	Order again
`database_name_taken`	`failed`	Another database took the name meanwhile	Order again with another name
`subnet_not_found`, `subnet_not_usable`	`failed`	The subnet was deleted, or failed, after you ordered	Order again into a usable subnet
`invalid_name`, `region_not_available`	`failed`	The request could not be built as given	Order again with a valid name and zone
`provisioning_failed`	`failed`	It was paid for but could not be built	Order again; contact support if it repeats
`organization_deleted`	`payment_failed` or `failed`	The organization was deleted before the database was built, so the order was cancelled	Nothing to do: any payment taken was returned to credit

When the build itself fails, failure_code may instead be the build operation's own code, such as DATABASE_DEPLOY_FAILED or DATABASE_SETUP_TIMED_OUT; treat it like provisioning_failed, and quote it to support if it repeats.

Whenever an order ends failed, anything it took is returned to your credit. A password held for a failed or expired order is erased with it.

List your orders

Terminal

$ curl "https://api.pantechdynamics.com/public/v1/database-orders?limit=20" \    -H "Authorization: Bearer $PANTECH_API_KEY"

Orders never include a password, only the admin_username the database is made with.

Retrying a create

Send the same request with the same Idempotency-Key and you get the same order back, never a second database or a second payment. The replay has password_returned: false and password: null: a generated password is only ever in the first response. If that first response was lost, wait for the database, then reset the password.

A different request body with a key you have used before is 409 IDEMPOTENCY_CONFLICT. Use a new key for a new database.

With the CLI

pantech db create places the order, prints a generated password once, and follows the order until the database is running:

Terminal

$ pantech db orders list$ pantech db orders get ord_…