# For partners: embed a receipt-bound verdict in 15 minutes For ERC-8004 explorers, agent venues, directories and toolkits. Every price in this guide is stated exactly as already recorded: the partner verdict price is the decided D1 price, and the partner bundle anchor is a recorded recommendation, not a decided price. Nothing is charged today — charged_today is false — because no partner billing rail is armed: partner verdict calls are metered by count only. Reading this guide is free and side-effect-free, and verification stays free. Guide data: https://www.a2ally.com/v1/partners/guide · Partner index: https://www.a2ally.com/v1/partners · Catalog: https://www.a2ally.com/services · Pricing: https://www.a2ally.com/pricing ## The 15-minute integration 1. Create an account and get the account key — POST /v1/accounts/signup. Create an a2ally account and keep its account key: in this slice the presented account key IS the partner key — the same key authenticates the register call and every metered verdict call. 2. Register as a partner — POST /v1/partners/register. Register or update the calling account's own partner profile with the account key: body partner_class, one of explorer, venue, directory, toolkit. The answer is the calling account's own partner document only — its pseudonymous account reference, partner_class, affiliated flag, the tier block and its own metering. 3. Call the partner verdict (metered) — GET /v1/partners/verdict/{slug}. With the account key, GET /v1/partners/verdict/{slug} for slug eip155-{chain_id}-{agent_id} serves one ERC-8004 identity's verdict: the identity citation, the deterministic verdict under the printed rule, liveness and receipt-bound reputation. Each served verdict (HTTP 200) is metered by count for the calling account; error answers are never counted. The same meaning document stays free without a key at GET /v1/erc8004-meaning/{slug}. 4. Embed the verdict — GET /v1/partners/card/{slug}. Embed the same verdict data three ways: the card document at GET /v1/partners/card/{slug} (free, no key, with the iframe and link snippets), the canonical human page at /agents/erc8004/{slug} (with a markdown twin), or the standalone embed page at /embed/erc8004/{slug} dropped into an iframe. Card, page and embed reads are free and side-effect-free — no metering increment; metering stays only on the verdict call in step 3. ## Neutrality commitments Neutrality: placement is never sold, and the subject of a verdict can never pay to alter, suppress or expedite it. That refusal is a feature of the partner program, stated here and printed on every trust card: a verdict is the deterministic output of the printed verdict rule over the live chain read, the live endpoint probes and the sealed ledger entries — nothing else moves it, for paying and non-paying subjects alike. ## Pricing, exactly as recorded Verdict API: $0.02/call — decision D1, status decided_recorded, charged_today: false. Nothing is charged today because no partner billing rail is armed; verdict calls are metered by count only. Partner bundle anchor: $99/mo — status recommended_recorded_not_decided: a recorded recommendation, not a decided price, and never charged. Rate limits are metered and printed, not enforced in this slice. Founder rule: the partner verdict is a new per-call fee line (feature partner_verdict), so it launches with 10 founder slots under the settled rule for new per-call lines, and an account may hold founder slots on at most 3 distinct fee features; beyond that cap the decided price applies. No founder claim is recorded by a partner verdict call in this slice, because a founder slot is claimed on first charged use of a fee feature and nothing is charged today — the claimed count below is read live from the founder registry and is zero until a charged-use claim path exists for this feature. ## Venue outcome ingest Venue outcome rule: POST /v1/partners/outcome-receipts with an account key (the partner key) records one venue outcome — venue_id, job_ref, seller_identity and buyer_identity (the two parties' resolved ERC-8004 identities, as slugs, which must differ), outcome_class (one of completed, completed_disputed, disputed, failed, ambiguous) and an optional note. The outcome is sealed to the ledger as an activity.receipt entry whose payload carries hashes and ids only, and stored as a sealed A10 input record attributed to the submitting venue as its source: the venue_id rides the record. All records on this surface are venue-self-reported — a venue reporting outcomes from its own venue is by construction reporting about itself — and every served record is labeled venue_self_reported. No live chain resolution happens on ingest. Outcome ingest is free: charged_today is false and no price exists on this surface. - completed — The job was completed and neither party disputes the outcome. - completed_disputed — The job was completed, but one or both parties dispute some part of the outcome. - disputed — The parties disagree about the job or its outcome and the job is not recorded as completed. - failed — The job was not completed. - ambiguous — The venue cannot classify the outcome confidently from the records it holds. A10 weighting rule: venue outcome records are sealed A10 INPUT RECORDS attributed to the venue; under A10's existing rules (the receipt-bound reputation graph, four inputs, unchanged) a standalone venue report scores ZERO direct points: the reputation graph is NOT modified, no new input or component is invented, and a venue outcome can corroborate but never substitute for the sealed marketplace records A10 already counts. All records on this surface are venue-self-reported. ## Partner zero: a2ally (affiliated) Partner zero: a2ally (affiliated) — a2ally's own surfaces render verdicts through the same partner card machinery a partner embeds (the card document composed from the meaning layer), labeled affiliated wherever partner activity is counted. The live card for ERC-8004 agent eip155-1-1, embedded through the same embed page any partner iframes: Canonical page: https://www.a2ally.com/agents/erc8004/eip155-1-1 · Card data: GET https://www.a2ally.com/v1/partners/card/eip155-1-1. Dogfood applies where the subject is an ERC-8004 identity — the canonical agent pages (/agents/erc8004/{slug}) and this guide. Other a2ally surfaces whose subjects are not ERC-8004 identities do not render ERC-8004 verdicts; they link to the card instead. Reading this section, the card, the canonical page or the embed creates no partner_verdict_calls metering increment and no other record. ## Callable surfaces - GET /v1/partners/guide (free, no key) — this guide document: the integration steps, the neutrality commitments, the decided D1 pricing and the partner tier block, the founder rule, and the partner-zero dogfood block - GET /for-partners (free, no key) — the partner guide as a page, with a markdown twin at /for-partners.md - POST /v1/accounts/signup — step 1: create an account and get its account key (the account key is the partner key in this slice) - POST /v1/partners/register (partner key: any account key) — step 2: register or update the calling account's own partner profile with partner_class - GET /v1/partners/verdict/{slug} (partner key: any account key) — step 3: one ERC-8004 identity's metered partner verdict by slug eip155-{chain_id}-{agent_id} - GET /v1/partners/card/{slug} (free, no key) — step 4: one ERC-8004 identity's trust card as data, with the embed snippets; reading it creates no metering increment - GET /agents/erc8004/{slug} (free, no key) — step 4: the canonical human page for one ERC-8004 identity, with a markdown twin - GET /embed/erc8004/{slug} (free, no key) — step 4: the standalone embed page for one ERC-8004 identity, suitable for an iframe - GET /v1/partners (free, no key) — the partner verdict index document: the rules, the pricing and tier blocks, the founder rule and live aggregate metering counts - GET /v1/partners/me (partner key: any account key) — the calling account's own partner document - POST /v1/partners/outcome-receipts (partner key: any account key) — venue outcome-ingest: submit one completed-job outcome (venue_id, job_ref, seller_identity, buyer_identity, outcome_class, optional note), sealed as an A10 input record attributed to the venue; the outcome classes and the A10 weighting rule are in this guide's outcome_ingest block - GET /v1/partners/outcome-receipts (partner key: any account key) — the calling account's own submitted venue outcomes only, with its own totals by outcome class