Skip to content

Provisioning Deep Links

A provisioning deep link takes a visitor from an external site (the Servala website, a partner page, a campaign landing page) straight into the service provisioning flow of the Servala Portal, optionally with the provider, zone, compute plan, SLA tier, storage size and replica count already selected.

Entry point

https://portal.servala.com/provision/<service_slug>/?provider=<slug>&zone=<slug>&plan=<slug>&sla=<code>&storage=<size>&instances=<n>

Only <service_slug> in the URL path is required. Everything else is an optional query parameter.

The entry point is organization-agnostic: the portal resolves the organization itself, so the linking site never needs to know which organization (or how many) the visitor has.

Always link to this URL, never to the internal instance creation form. The internal form URL contains numeric organization and offering IDs, which are not stable external identifiers.

Parameters

Parameter Location Required Value
service_slug URL path yes Service slug, for example postgresql
provider query no Cloud provider slug, for example exoscale
zone query no Service provider zone slug, unique within a provider, for example ch-gva-2
plan query no Slugified compute plan name, for example standard-2
sla query no SLA tier code, for example nosla or guaranteed
storage query no Kubernetes storage quantity, for example 50Gi or 100
instances query no Replica count as a positive integer, for example 3
org query no Organization slug, rarely set by the linking site (see below)

Notes on the values:

  • provider, zone and plan are matched by slug, not by display name or numeric ID. Provider and zone slugs are stored fields intended as stable deep-link identifiers. plan is matched against the slugified compute plan name, so Standard 2 becomes standard-2.
  • sla is matched against the SLA tier code.
  • storage is passed through as a raw Kubernetes storage quantity string. It must match the pattern ^\d+(Ki|Mi|Gi|Ti|Pi|K|M|G|T|P)?$, so a plain number or a number with a binary or decimal unit suffix.
  • instances pre-fills the replica field of the service's main component and feeds the live price preview, so the price shown already reflects the requested replica count. Values that are not positive integers are ignored.
  1. Authentication. The endpoint requires a login. Visitors who are not signed in go through SSO first. The full provisioning intent is stored in the session and replayed after login, so no parameters are lost.
  2. Organization. If the visitor belongs to exactly one organization, it is used automatically. If they belong to several, the organization chooser is shown, which re-enters the same /provision/... link with &org=<org-slug> appended. If they belong to none, they are sent into organization onboarding and the intent is resumed afterwards. The linking site normally does not send org: the portal handles the selection.
  3. Service. Resolved from <service_slug> against the services available to the chosen organization. An unknown or unavailable service shows a warning and lands the visitor on the service list.
  4. Provider and offering. provider selects the matching offering. If provider is omitted and the service has only one offering, that offering is selected automatically. With several offerings and no valid provider, the offering chooser is shown.
  5. Zone, plan, SLA, storage, instances. Forwarded into the creation form as pre-filled values. Any value that does not resolve (for example a zone that the chosen provider does not offer) is skipped with a non-blocking warning, and the visitor can still complete the form manually.
  6. The visitor lands on the pre-filled instance creation form and completes provisioning as usual.

Behaviour

Graceful degradation
Every optional parameter that cannot be resolved is dropped with a user-facing hint instead of failing the whole link. A bare /provision/<service_slug>/ always works and simply opens the service's creation flow with nothing pre-selected.
No information leak
Unknown or foreign organizations are treated as if no organization had been specified.
Stable identifiers only
Build links from service, provider and zone slugs plus the slugified plan name and the SLA code. Never use numeric database IDs.

Examples

Open PostgreSQL provisioning without any preselection:

https://portal.servala.com/provision/postgresql/

Pre-select provider and zone:

https://portal.servala.com/provision/postgresql/?provider=exoscale&zone=ch-gva-2

Fully specified, including a three-replica cluster:

https://portal.servala.com/provision/postgresql/?provider=exoscale&zone=ch-gva-2&plan=standard-2&sla=guaranteed&storage=50Gi&instances=3

Where the slugs come from

The linking site should source the slugs from the same service catalog data it already synchronizes with the portal:

  • service_slug: the service slug
  • provider: the cloud provider slug
  • zone: the control plane slug, labelled "Service Provider Zone" in the portal and unique per provider
  • plan: the compute plan name, slugified
  • sla: the SLA tier code