Deployment availability

A small set of routes exists only on the deployment Fluxer hosts. An operator 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. A caller cannot tell an unavailable route from an unrecognised path.

The API decides registration once at process start from the deployment configuration. No credential, permission, premium state, or OAuth2 scope changes the answer. A client resolves the deployment kind from instance discovery.

Deployment kind

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

stripe_enabled on the same object reports the payment provider toggle alone. 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.

Without a provider client, 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. Three 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, and 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/gifts¹	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/webhook²	Receive Stripe webhook
POST	/v1/users/@me/age-verification¹	Create age verification session
GET	/v1/premium/refund-eligibility³	Get refund eligibility
POST	/v1/premium/refund-latest	Refund latest purchase
GET	/v1/premium/price-ids	Get price IDs
GET	/v1/premium/current-subscription-price⁴	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 two 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, because a self-hosted deployment grants premium to every account only while its instance premium mode is everyone. While that mode is in force it 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 switch off a capability that the surrounding routes still expose, so a client reads the flag.