a month ago
I build Vibe Costs, a dashboard that lets developers aggregate live software and infrastructure costs.
Railway already exposes currentUsage, usage, estimatedUsage, and agentUsage through GraphQL, and the CLI's usage command uses these fields. Existing Central Station answers also confirm that project usage can be queried. The remaining integration questions are:
- Are these queries officially supported for a customer-authorized third-party OAuth app using the read-only workspace:viewer scope?
- Can Railway expose provider-calculated project and service dollar attribution, credits, freshness, and finalization state so integrations do not have to reproduce Railway's pricing engine?
The important constraint is least-privilege third-party OAuth. We do not want customers to hand Vibe Costs a personal token, project token, or credential that can modify infrastructure.
Technical proposal and schema:
https://vibecosts.app/cost-api/docs
I can build and maintain the connector once the supported OAuth query surface is confirmed, and I am happy to test it against my own workspace.
0 Threads mention this feature
1 Replies
a month ago
Concrete implementation update: we now have the consumer-side reconciliation flow working against a dummy Cost API provider. One OAuth grant can expose multiple billing accounts; users explicitly match, create, or ignore each account; manual history is retained across a date-windowed cutover; reconnects deduplicate by stable account ID; and estimated costs can finalize without double counting.
For Railway, the minimum connector is a selected workspace ID, billing currency and time zone, provider-calculated billed cost for an explicit period, cost status plus updated_at, and optional project/service items under workspace:viewer or a dedicated billing:read scope.
Could someone confirm whether currentUsage, usage, and estimatedUsage are officially supported for third-party OAuth and point me to the owner of this surface? I can implement and test immediately.