fluxer/fluxer_docs/src/content/docs/http-api/deployment-availability.md

title, description

title	description
Deployment availability	The hosted-only routes and the instance flags that report deployment kind.

The routes listed under Hosted-only routes exist only on the deployment Fluxer hosts. A self-hosted deployment runs the same release, and most of the HTTP API is identical on both.

A self-hosted deployment does not register those routes. A request to one returns 404 NOT_FOUND with no feature-specific code, so a caller cannot tell an unavailable route from an unrecognised path.

Credentials, permissions, premium state and OAuth2 scopes do not change route availability. Read the deployment kind from instance discovery.

Deployment kind

Every deployment reports its kind in self_hosted on the instance features object. The unauthenticated instance discovery document publishes it before a client holds any credential. self_hosted alone decides whether the API registers the routes below.

stripe_enabled on the same object reports only the integrations.stripe.enabled configuration value. A hosted deployment that reports it false still serves every route in the table below. A deployment reporting stripe_enabled true with no provider secret key configured behaves exactly like one reporting it false.

:::caution[Read self_hosted for the deployment kind] Neither flag promises that a provider-dependent operation succeeds. :::

When stripe_enabled is false or no provider secret key is configured, the answer depends on the operation. An operation that has to reach the provider fails with 400 STRIPE_PAYMENT_NOT_AVAILABLE, and Receive Stripe webhook fails with 400 STRIPE_WEBHOOK_NOT_AVAILABLE. These read operations report the absence in a 200 body instead:

• Get refund eligibility reports eligible false with the reason feature_unavailable.
• Get current subscription price reports null.
• Get price IDs reports the configured price IDs with every amount null.

Hosted-only routes

Method	Route	Operation
POST	/v1/donations/request-link	Request donation management link
GET	/v1/donations/manage	Manage donation
POST	/v1/donations/checkout	Create donation checkout
GET	/v1/gifts/{code}	Get gift
POST	/v1/gifts/{code}/redeem	Redeem gift
GET	/v1/users/@me/gifts1	List current user gifts
POST	/v1/stripe/checkout/subscription	Create subscription checkout
POST	/v1/stripe/checkout/subscription/preapproval	Create localised card preapproval
POST	/v1/stripe/checkout/subscription/preapproval/continue	Continue localised card preapproval
POST	/v1/stripe/checkout/gift	Create gift checkout
POST	/v1/stripe/webhook2	Receive Stripe webhook
POST	/v1/users/@me/age-verification1	Create age verification session
GET	/v1/premium/refund-eligibility3	Get refund eligibility
POST	/v1/premium/refund-latest	Refund latest purchase
GET	/v1/premium/price-ids	Get price IDs
GET	/v1/premium/current-subscription-price4	Get current subscription price
POST	/v1/premium/customer-portal	Create customer portal
POST	/v1/premium/grace/end	End premium grace period
POST	/v1/premium/cancel-subscription	Cancel subscription
POST	/v1/premium/reactivate-subscription	Reactivate subscription
POST	/v1/premium/change-subscription	Change subscription billing cycle
POST	/v1/premium/cancel-pending-subscription-change	Cancel pending subscription change
POST	/v1/premium/visionary/rejoin	Rejoin Visionary guild

¹ These are the only /users/@me routes a self-hosted deployment does not serve

² The webhook takes no credential and is authenticated by the provider signature header alone

³ The same object appears as billing.refund_eligibility on Get premium state, which every deployment serves, and there a self-hosted deployment reports eligible false with the reason feature_unavailable

⁴ The same object appears as billing.current_subscription_price on Get premium state, which every deployment serves

Registered routes that resolve differently

A route every deployment registers can still produce a different answer on a self-hosted instance. Each operation page documents that difference.

Premium state is the clearest case. Every deployment registers Get premium state and Set premium perks disabled. A self-hosted instance still reports premium state and still records the perks-disabled flag. The response repeats the deployment kind in self_hosted on the effective premium state object. That flag alone does not make is_premium true. A self-hosted deployment grants premium to every account only while its instance premium mode is everyone. That mode also overrides the perks-disabled flag, so is_premium stays true while premium_perks_disabled is true.

The other instance feature flags published by instance discovery work the same way. voice_enabled, presigned_attachment_uploads, and emails_enabled each report whether a capability is switched on. The routes for that capability stay registered when the flag is false, so a client reads the flag before it uses them.