Documentation navigation

Credits and pricing

Operations are priced in credits drawn from one pooled account balance. There is no per-seat metering and no separate wallet per key.

Every operation publishes its own price

Each operation in the reference carries its price two ways: a one-line policy footer at the end of its description, and a machine-readable x-vamo block you can read straight out of https://api.vamotalent.ai/openapi.json.

Prices come in three shapes:

  • Free. No charge, ever. Reads of your own account, plans, and identity are free.
  • Flat. A fixed number of credits per call.
  • Metered. A number of credits per unit, where the unit is stated in the footer. The most common unit is a result actually returned, so a search that returns nothing costs nothing.

Preview before you spend

Any priced request accepts ?vamo_estimate=1. The request is validated and priced, the predicted cost and your remaining allowance are returned, the handler never runs, and nothing is charged. This is the supported way to budget a large batch.

After a real call, the x-cost response header carries what was actually debited.

The public price list

GET /v1/pricing/catalog is public and free. It returns:

  • the sellable plans,
  • creditUsd, the dollars per credit rate,
  • every facet, what it gives you, and what it costs,
  • the SKUs facets are grouped into, and the bundles.

The catalog is read from the same source the biller charges from, so it cannot drift from what you are billed. Do not hardcode prices; read them from here.

Facets are sold as SKUs

A facet is one enriched fact about one developer. Facets are grouped into SKUs, and the price is per SKU, per developer.

This has a consequence worth planning around: naming one facet in a SKU and naming every facet in that SKU cost the same. If you want two signals from the same SKU, ask for both in the same request rather than paying twice across two requests. See Enrichment and facets.

You are not charged twice for the same fact

When your account is billed for a facet on a developer, the account is granted ownership of that facet for that developer. Ownership means two things:

  • Re-reading is free. Ask for the same facet on the same developer again and you are not billed again while the grant is live.
  • Access does not expire. An ownership grant keeps giving you the newest value we hold for that fact. Expiry governs price, not visibility. You never lose access to something you paid for.

Cached values are shared across all customers, but ownership is per account. Another customer having already computed a fact makes it fast for you, not free for you. You pay the first time you ask for it.

Practical consequences:

  • Re-running the same enrichment nightly on a stable list of developers does not multiply your bill.
  • Widening a list does. You pay for the developers you added, not the ones you already owned.
  • Because facets bill per SKU, request every facet you want from one SKU in a single call. Two calls for two facets in the same SKU can cost twice what one call for both would.

If you want certainty before a large batch, send it with ?vamo_estimate=1 first. The estimate accounts for what you already own.

Balance and history

  • GET /v1/account/credits is the current balance.
  • GET /v1/account/credits/ledger is the itemised history of what was spent on what.
  • GET /v1/quotas is your allowances, which are separate from your balance. A quota can stop a call even when you have credits.