Job Opportunities API

Check the data. Then trust it.

account

Billing, invoices and status

What happens between clicking buy and the key switching on, where the invoice comes from, and how to tell whether the data behind the API is current.

Last verified 2026-08-22 · Assumes: Plans. · Markdown copy

1Checkout

Pick a plan, enter your details, pay by card. The key is created immediately in a pending state and switches on when the payment confirms.

In depthWhy it exists, what it is not, what people get wrong

Card payments are handled by Viva, the payment service provider; the card details are entered on their page and never reach this site. The site's own checkout collects what an invoice needs — name, email, country, and a VAT number if you have one — and hands the order to the gateway.

The key row is written before the payment completes, in a past_due state. That is why a key can appear on your dashboard showing Awaiting payment: it is not an error, and it needs nothing from you beyond finishing the payment. When the gateway confirms, a webhook activates it.

Exact contractTypes, defaults, ranges, errors, edge cases
  1. /pricing or /apiGet access/checkout?plan=<plan>.
  2. The form posts to the site's own /api/checkout, which forwards to POST /public/checkout on the API.
  3. The API validates the plan against the live plans table, computes VAT for your country, writes a pending key, and creates an order at the gateway.
  4. You are redirected to the gateway's card page.
  5. On success you land on /checkout/done; on failure, /checkout/failed. Neither page is what activates the key.
  6. The gateway's webhook activates the key. This is the authoritative step — the redirect is only a redirect.

A legacy webhook path for a previous provider (Revolut) still exists in the API and is retained for historical orders. Live checkout does not use it.

2Invoices and credit notes

An invoice is issued for every completed order and reached by an unguessable link, so it works from an email with no sign-in.

In depthWhy it exists, what it is not, what people get wrong

The invoice URL carries a token in the path (/invoice/<token>) rather than requiring a session, because the person opening it is usually doing so from a mail client — often somebody in finance who has no account here. A challenge or a login wall in front of that link makes it a dead link.

A refund or a correction produces a credit note rather than an edit to the original document. That is a legal requirement, not a preference: an issued invoice is not modifiable after the fact.

For anything the dashboard does not cover — a copy, a VAT number added after the fact, a purchase-order reference — /contact?topic=billing reaches a person.

Exact contractTypes, defaults, ranges, errors, edge cases
VAT
Computed at checkout from your country and whether you supplied a VAT number. Business customers in other EU member states with a valid number are reverse-charged.
Currency
EUR throughout.
Document types
Invoice for orders; credit note for refunds and corrections. Retail and business documents are issued under different classifications.
Access
/invoice/<token> — no session required, token in the path.
Copies
Ask at /contact?topic=billing.

3Fiscal transmission (Greece, myDATA)

Invoices are transmitted to the Greek tax authority's myDATA platform. It affects what an invoice must contain, not what you have to do.

In depthWhy it exists, what it is not, what people get wrong

The business is registered in Greece, so every issued document is transmitted to AADE's myDATA platform. For a customer this is invisible; it matters here only because it constrains the invoice, and two of those constraints occasionally surprise people.

A name is required on a retail document
The customer is a person, not a VAT number. The tax authority enforces this, so the checkout asks for a name even when you supply a company VAT number.
Corrections are credit notes
A transmitted document cannot be edited. A correction is a new, related document.
Exact contractTypes, defaults, ranges, errors, edge cases

Documents are classified as business-to-business or retail, with the corresponding myDATA income classification and document type, and credit notes are filed as related documents against the original. Payment method is recorded as card. None of this requires anything from you; it is documented because a customer asking “why does this invoice look like that” deserves an answer that is not “because the system does it”.

4Status — is the data current?

/status answers whether the ledger is current, measured from the ledger itself, not whether the website replied to a ping.

In depthWhy it exists, what it is not, what people get wrong

A green dot on a conventional status page proves the site answered a probe. That is not the question a data buyer has. The question is whether the data moved — how much was re-verified in the last day, how much was added, how much was delisted, and how old the oldest verification is. Those are what /status reports, and all of them are read from the ledger.

The same figures are available programmatically at /public/status (keyless), and the deeper freshness report at `/public/freshness`.

Exact contractTypes, defaults, ranges, errors, edge cases
What `/status` reportsRead it as
stateok, degraded, or worse — computed from the figures below, not from a probe.
live_listingsRows currently servable.
reverified_last_24hRows re-confirmed at their source in the last day. The main sign of a healthy refresh.
added_last_24hNew rows in the last day. Absent — shown as — where the stored snapshot predates the measurement.
delisted_last_24hRows that left in the last day.
oldest_verificationHow stale the least recently checked row is.
last_projectionWhen the served set was last rebuilt.

A missing figure renders as rather than as 0, deliberately: a real zero and “not measured yet” must not look alike. Every number on that page comes from an endpoint that can legitimately not have measured something yet.

This page was rendered 11 September 2026, 18:36 UTC. Every figure on it comes from the endpoint named beside it, and every published request is re-sent against the live API before this site is allowed to build. If something here is wrong, the thumbs-down above reaches a person.