API Billing Readiness
Before submitting service applications through the API, check which billing arrangement applies to the tenant and whether the account is configured for API consumption. This check is advisory: it does not reserve capacity, approve an invoice, guarantee funds or provider fulfillment, or change submission, payment, or authentication rules.
Choose a billing mode
Fluxir supports two different experiences:
- Portal: use the Travel Agencies Portal for interactive workflows such as Stripe Checkout. Checkout is a portal payment flow, not a headless API billing arrangement.
- Headless API: use API credentials and the tenant-scoped readiness request below. Headless clients should coordinate billing setup with their Fluxir administrator or support contact before paid submission.
A tenant may be configured for invoice-based billing. Invoice approval remains an explicit, staff-controlled billing execution step. Readiness does not infer approval from an invoice, balance, Marketplace status, or Stripe Checkout completion.
Check readiness
First follow the authentication guide to obtain a bearer token. Then request readiness for the tenant represented by the token:
curl --request GET 'https://api.fluxir.com/api/app/billing-readiness/current' \
--header 'Authorization: Bearer <ACCESS_TOKEN_VALUE>' \
--header 'X-Tenant: <YOUR_TENANT_ID>' \
--header 'Accept: application/json'
The current-tenant readiness endpoint documents the generated API contract. Authorized delegated clients can instead use the specific-tenant readiness endpoint with a UUID path parameter. Do not use that route to probe tenants without delegated authorization.
A successful response uses these fields:
| Field | Meaning |
|---|---|
status | READY, NOT_READY, NOT_BILLABLE, or UNKNOWN. |
billingArrangement | Informational arrangement: Invoice, None, or Unknown in the current implementation. It is not the readiness decision. |
reason | Human-readable explanation returned by the service. |
nextActions | Suggested action objects with code, title, description, and an optional trusted url. |
tenantMode | Production or Test. Test mode describes the tenant mode; it does not promise no-charge execution. |
evaluatedAt | UTC time when the response was evaluated. |
dataAsOf | UTC time of the source data, or null when source data is unavailable. |
Ready
{
"id": "11111111-1111-4111-8111-111111111111",
"status": "READY",
"billingArrangement": "Invoice",
"reason": "Your account is configured for API consumption",
"nextActions": [],
"tenantMode": "Production",
"evaluatedAt": "2026-09-17T10:30:00Z",
"dataAsOf": "2026-09-17T10:30:00Z"
}
READY means the tenant is billable and deferred payment is not prohibited. It does not mean that an invoice has been approved, that a provider will accept a later submission, or that a charge will be zero.
Action required or not billable
{
"id": "22222222-2222-4222-8222-222222222222",
"status": "NOT_READY",
"billingArrangement": "Invoice",
"reason": "Deferred payment is prohibited for this account",
"nextActions": [
{
"code": "CONTACT_BILLING",
"title": "Contact Billing Staff",
"description": "Your account requires explicit payment or approval before submission. Contact your billing administrator.",
"url": null
}
],
"tenantMode": "Production",
"evaluatedAt": "2026-09-17T10:31:00Z",
"dataAsOf": "2026-09-17T10:31:00Z"
}
For NOT_READY, ask the billing administrator which approved payment or approval step applies. For NOT_BILLABLE, contact Fluxir support or the account administrator to discuss eligibility. Do not treat either response as an instruction to create an invoice or make a payment through an unapproved channel.
Unknown, errors, and permissions
UNKNOWN is a valid response status for an incomplete readiness result. Treat it as an advisory failure: do not guess the billing state, and contact support with the response timestamps and your correlation ID. A partial-source example is:
{
"id": "00000000-0000-0000-0000-000000000000",
"status": "UNKNOWN",
"billingArrangement": "Unknown",
"reason": "No tenant context found",
"nextActions": [
{
"code": "CONTACT_SUPPORT",
"title": "Contact Support",
"description": "Unable to determine your billing readiness. Please contact Fluxir support.",
"url": null
}
],
"tenantMode": "Production",
"evaluatedAt": "2026-09-17T10:32:00Z",
"dataAsOf": null
}
An authentication failure is not an UNKNOWN business result. Handle the HTTP status first:
401 Unauthorized: obtain a valid access token and retry without logging or exposing the token.403 Forbidden: the token is authenticated but is not allowed to inspect the requested tenant. Do not retry by changingtenantIdor disclose whether another tenant exists.500 Internal Server Erroror another service error: record the response status, request timestamp, and correlation ID, then contact support. Do not treat a failed request asREADY.
ABP error responses use the configured RemoteServiceErrorResponse shape, for example:
{
"error": {
"code": "Forbidden",
"message": "You are not authorized to perform this operation.",
"details": null,
"data": null,
"validationErrors": null
}
}
Before paid submission
- Authenticate with the intended tenant and inspect readiness close to the planned submission time. Compare
evaluatedAtanddataAsOfwith your own freshness policy. - If the result is
READY, continue with the existing submission validation and payment workflow. Readiness does not bypass schema, authorization, tenant, application, or provider validation. - If an action is returned, follow only the action details supplied by Fluxir or your authorized administrator. The current actions are advisory and may not include a URL.
- If the result is
UNKNOWN,401,403, or a service error, pause and resolve the configuration or access issue with the administrator/support team.
Do not send access tokens, client secrets, passport images, or passport numbers to support. Share the tenant ID only through an approved support channel, along with the correlation ID, status, reason, and timestamps.
Test tenants are identified by tenantMode: "Test", but that label is not evidence that every operation is free, that providers will fulfill requests, or that production billing rules are simulated identically. Confirm test scope and expected charges with Fluxir before running paid or provider-backed scenarios.