set_plan

{
  "name": "set_plan",
  "resource": "application",
  "tier": "reversible",
  "clients": [
    "bearer",
    "browser_session"
  ],
  "summary": "Move one application between the Free, Standard, and Pro plans: the entitlements the plan carries — the replica floor and the database role's connection limit — are applied before the plan is recorded, the application's three usage states are recomputed against the new plan's served quantities before the change is answered in either direction (a raise clears an over state at once, a move to a smaller plan with figures over its quantities is admitted and records over, so the serving router refuses within its resolve interval), and the answer names the entitlements and the recomputation; a second Free application of the account refuses `free_application_limit`, a plan with an Unset served quantity `plan_quantity_unset`, and a failed entitlement `entitlement_apply_failed` with the plan unchanged. Through the beta, a move onto Standard or Pro past the account's per-plan limit refuses `beta_plan_limit`.",
  "annotations": {
    "readOnlyHint": false,
    "destructiveHint": true,
    "openWorldHint": true
  }
}

{
  "name": "set_plan",
  "tier": "reversible",
  "scenario": "CHI-L0-09",
  "summary": "Move one application between the `free`, `standard`, and `pro` plans. The plan's entitlements — the replica floor and the database connection limit — are applied first and the plan recorded last. The application's usage states are recomputed against the new plan before the answer, so a larger plan clears an `over` state at once and a smaller plan with figures over its quantities records `over` at once; the answer names both. A second free application refuses `free_application_limit`; a plan whose quantity the operator has not set refuses `plan_quantity_unset`. Through the beta, a second `standard` or a second `pro` application of the account refuses `beta_plan_limit`. A running copy keeps its injected `APP_DATABASE_CONNECTION_LIMIT` until its next deploy, promote, or `restart_application`, and the answer's `detail` names the restart for each environment whose running copy has a database.",
  "owners": [
    "ACB-L0-22",
    "ACB-L0-26",
    "PRC-L0-04",
    "ACB-L0-83"
  ]
}

{
  "request": {
    "type": "object",
    "required": [
      "application",
      "plan"
    ],
    "properties": {
      "application": {
        "type": "string",
        "description": "The application id, from `list_applications`."
      },
      "plan": {
        "type": "string",
        "enum": [
          "free",
          "standard",
          "pro"
        ],
        "description": "`free`, `standard`, or `pro`. Through the beta, moving onto `standard` or `pro` while the account already holds its one live application on that plan refuses `beta_plan_limit`."
      }
    }
  },
  "response": {
    "type": "object",
    "required": [
      "contract_version",
      "application"
    ],
    "properties": {
      "contract_version": {
        "const": 1
      },
      "reference": {
        "type": "string",
        "pattern": "^[0-9a-f]{10}$",
        "description": "The short reference the platform recorded this call under, ten lowercase hexadecimal characters, the value the call’s record row carries; quote it when reporting the call."
      },
      "application": {
        "type": "object",
        "required": [
          "id",
          "label",
          "plan",
          "warm_floor",
          "connection_limit"
        ],
        "properties": {
          "id": {
            "type": "string"
          },
          "label": {
            "type": "string"
          },
          "plan": {
            "type": "string",
            "enum": [
              "free",
              "standard",
              "pro"
            ]
          },
          "warm_floor": {
            "type": "integer",
            "description": "the replica floor the plan gives (PRC-L0-05; PLD-L0-63): 0 for free, 1 for standard and pro"
          },
          "connection_limit": {
            "type": [
              "integer",
              "null"
            ],
            "description": "the plan's served `database-connection-limit` quantity: the connections each process of the application holds open at once, the client pool's maximum, which the pool reads from `APP_DATABASE_CONNECTION_LIMIT`. The role's CONNECTION LIMIT admits twice it, the second half a deploy's overlap of the previous and the new container, so a pool of this size is refused nothing (DBS-L0-04). The member is answered whatever the manifest declares, and it governs the application's client pool once the manifest declares the database kind; `read_plan_quotas` answers every plan's"
          }
        }
      },
      "detail": {
        "type": "string"
      }
    }
  }
}