Epovest

Bring a check of your own back to the checklist of a surface, with the cells it had: it becomes work again, so the page needs it verified to count as aligned. The checks to bring back are listed by list_surfaces in checklist.custom, with deleted true. Restoring a check already in the checklist answers the same.

Set the addresses of the brand that are neither its canonical website nor a page of the surface registry: a satellite domain the customer does not want to keep aligned, a tracking link, a partner page. They are set ONCE for the project and serve every line of the corroboration registry, present and future, so there is nothing to set line by line. The list you send REPLACES the previous one, and the answer returns what the project now holds, derived addresses included: read it back to confirm. An empty list keeps only the derived ones. Call get_link_targets first, and confirm with the user before replacing.

Arm a prepared scan: the engine is asked, and the prepaid balance is debited by the amount `estimated_cost_minor` announced on the scan. SPENDS: read that amount to the person and get their go-ahead before calling. The answers land within a few minutes; read the places back with get_competitor_scan. Safe to replay: a scan already armed answers with itself instead of paying for a second one.

Start or restart the measurement of a tracker against the prepaid credit balance. The first survey runs there and then, whatever the frequency, unless the tracker carries a next_survey_at still in the future: with one set, nothing runs until that moment, which is how a tracker comes back on a date of the person's choosing. Restarting a paused tracker picks its schedule back up, at whatever configuration it carries now. Refused with insufficient_credits when the balance does not cover one survey; that answer carries top_up_url, the page where the person adds credit, so give it to them. Starting an already active tracker changes nothing.

Run one survey of a measuring tracker right now, on top of its schedule. Its settings stay as they are: same anchor, same frequency, and the next scheduled survey keeps its date. On a tracker whose frequency is on_demand, this is how every survey after the first one happens. It debits the prepaid credit balance like any survey, and the point joins the score series marked on_demand. The answer carries the survey id: read the results back with get_results, or the raw answers with get_responses. While one is still running, calling again answers that survey instead of starting a second one. Refused with insufficient_credits when the balance does not cover it, and that answer carries top_up_url, the page where the person adds credit, so give it to them. Refused with tracker_not_active when the tracker is not measuring yet: start_tracker first.

Record what a surface actually carries, cell by cell, as many moves as you want in one call. The items are listed by list_surfaces as checklist.items: the template of the surface type (stable keys such as title_tag or llms_txt), then the checks the customer added of their own (add_surface_check), which tick here exactly like the rest, at their key. Most of them are yours to check (a title tag, JSON-LD, an llms.txt all read with a simple fetch). Three moves per cell. VERIFY (done true, or nothing): the item is constated on the page; an item of canon kind (checklist.kinds) is stamped with the current canon version and wording, so its verification stays fresh until the wording moves, and needs the canon set first. SET ASIDE (dismissed true plus a short reason): the item does not apply on THIS surface (an author bio, a field the platform does not offer); durable across canon revisions, reversible, never hidden from the counts. CLEAR (done false, or dismissed false): the cell returns to blank. A site-wide item (checklist.site_items: the llms.txt, one file at the root of the site, written in the canonical language of the project) is one cell for the whole site, without a language. Only the cells you send change; an unknown item or language, a set-aside without reason or a contradictory move refuses the whole batch and says what exists. The ALIGNED status derives from the cells listed in checklist.required, the canon items plus the checks of the customer: verifying the last one aligns the surface and dates it in the journal. The goal is a surface with no required cell left undecided: work every one of them to a verdict, verified when the page carries it or set aside with a reason when the item does not apply here. Leaving a cell untouched is not a neutral skip, it holds the surface in needs_update and hides whether the page was ever checked, so go through the whole checklist and not only the cells easy to confirm. And setting aside the LAST canon cell is refused, because…

Prepare a top-up of the prepaid credit balance and return the hosted payment link. Nothing is charged by this call: hand payment_url to the user, the payment happens there, and they approve the amount on that page. When the user names an amount, that amount wins: pass it as `amount`, exactly the number they said. Amounts are always in the wallet currency of the account, which get_credits gives: if they name another currency, tell them, never convert one currency into another yourself. When they leave it to you, take one of the amounts get_credits already suggests in `suggested_topups[]` and pass its `amount_minor`: they are derived from what this account consumes, they clear the floor, and each says the runway it buys in `covers_months`. Name the one you picked and what it covers. Nothing to compute, and nothing to convert. Send one of the two, never both. The minimum top-up is 10.00 (1000 minor units). Once paid, the balance updates on its own and paused trackers resume.

Change the settings of the account. Send only what the user is changing: every setting you leave out keeps its value. `billing_country`, `billing_address` and `intra_eu_vat_number` clear when you send null; `name`, `language` and `timezone` keep their value on null, so name the language or the time zone you want. A postal address and a VAT number travel with `billing_country`: send the country in the same call. What you write here goes on the next invoices of the account, and the invoices already issued keep the details they carry.

Correct a scan still in draft, and set the cadence of one already armed. `questions` is where the measurement is won: send the questions to KEEP, with the wording you want asked. A question of the scan left out of the list is removed, and the amount announced by `estimated_cost_minor` follows, so this is also how the person spends less. Nothing is charged until start_competitor_scan, so rewriting costs nothing; a scan already measured keeps its questions (409) and a new one asks something else. `rescan_cadence` sets how often an armed scan runs again: "weekly" or "monthly" sets it, null stops it. Weekly widens the list faster and spends as often; monthly follows the pace a corpus of third-party pages moves at. Each pass widens the list rather than refreshing it, because two checks of the same question do not cite the same pages, and what one check found the next one keeps. SPENDS on every pass, the same amount as the first one, so name it to the person before setting a cadence. It states a STATE and replays safely both ways: setting the cadence already in place moves nothing, and stopping it leaves the accumulated list intact.

Update the sheet of a corroboration: only the fields you send change (an empty label goes back to the derived one, an empty notes or published_on clears it). Correcting the url ALWAYS recomputes the source: the two never drift apart. It also carries monitoring, the cadence at which the page is read again on its own, which is why watching a page needs no tool of its own. To say a page is gone, use archive_corroboration instead: editing never takes anything down.

Edit a manual logbook entry: only the fields you send change (empty notes clear them). It is the customer's own logbook: a typo or a wrong date is simply corrected. quest_id files an entry under a quest after the fact, and null files it back under the project alone. Tool events cannot be edited: they are derived from the canon and surface registries.

Revise the brand canon of a project. Field by field: a provided field replaces the current wording (an empty string clears it), an omitted field is kept as is. Any actual change records the NEXT canon version (numbered, immutable; version_created true in the answer); sending identical wording records nothing. The canon lives in ONE language, its canonical language (canon_language): it is never translated, changing the language is a revision like any other. The canon is meant to be STABLE: revising it is a rare and deliberate move, and every surface that reuses the wording will need to be brought back in phase with the new version. Confirm with the user before revising.

Edit a quest: only the fields you send change (empty notes clear them). It is the customer's own file: a typo or a sharpened wording is simply corrected. The status changes through its own moves, complete_quest, dismiss_quest and reopen_quest.

Update the registry sheet of a surface: only the fields you send change (a sent languages list replaces the previous one; an empty label or notes clears it). No journal line is ever written here: an alignment is earned with tick_surface_checklist, cell by cell. Languages ARE the columns of the checklist, so declaring the language of a single-language page renames its column and carries its verified cells along. When the change leaves no single destination (a language dropped from a page that keeps others, one column split into several), the columns that leave the model come back in dropped_checklist_columns with what they held; their cells stay stored, and declaring the language again brings them back. The status of the answer is derived from the cells that read NOW, so read it back rather than assuming it held.

Correct a check of your own on a surface: its label, and whether it restates the canon. Only what you send changes. The key never moves, being the coordinate of the cells already recorded, so renaming a check keeps every tick it carries. Turning restates_canon on makes a tick recorded without a canon stamp perish, which is the honest reading: the page was never checked against a wording.

Update the configuration of a tracker: only the fields you send change. Keywords, analysts and the title apply in place. Changing the prompts, engines, frequency or resolution of a version that HAS measured creates a new version: the score series continues across versions, and the response carries the new tracker id (version_created says when). A version that has not measured yet is amended in place and keeps its id, so version_created is false. A PAUSED tracker takes all of it, the collection settings included: the call writes the configuration and nothing else, no survey runs and no credit is spent, and what you set takes effect at the next start_tracker. That is the way to move a paused tracker to fewer engines or a slower frequency before paying for another survey. Send next_survey_at to say when that survey runs. A sent list replaces the previous one entirely.

Read the page again and report what it says today. One pass returns two findings, dated, and included at no cost. On the MENTION: the passage around the brand is archived on the line (the sentence that names it, one before, one after), and the finding says unchanged, changed (the passage moved, worth re-reading), figures (the passage moved on NUMBERS only, such as a rank or a counter: a fact to read, and changed_at stays where it was) or gone (the page did not answer). When a change was found, excerpt_before carries the passage as it stood BEFORE changed_at: compare it with excerpt to state what moved, in words, without reading the whole page. On the LINK: every link of the page towards an address of the brand, derived from the canon website and from the surface registry of the project, with its rel tokens (nofollow, sponsored, ugc, or none), its target and title attributes, its anchor text, its exact destination with the resolved redirect chain and the HTTP code of that destination, whether it sits in the main content or outside it, and its dates; the finding says unchanged, changed (changes lists what moved: rel, anchor, target, placement, appeared), gone, or none, which means the page carries no such link and is a normal state. The reply also carries how the page reads (readability: "html" when it reads, "blocked" when an anti-bot stands in front of it, "unreachable" when it did not answer, "no_page" when the address answers with something that is not a page, "unreadable" when it answers HTML with no text in it, "pending" while no reading has completed yet), the number of outbound links of the page, and what the page declares about itself (noindex, page_nofollow, canonical_elsewhere). Read readability before deciding a move: an anti-bot is a fact of the world, while a page that did not answer is worth reading again. Everything here is a FACT: the third party has the final say, so nothing closes, nothing counts, and nothing is taken down on its own. Use it to dec…