# Apostl full agent-readable content

Source: https://apostl.dev/index.md
Canonical HTML: https://apostl.dev/

# AI Agent Onboarding & Developer Journey Testing | Apostl

Test public SDK, API, and documentation journeys with AI agents, capture reproducible blockers, and keep developer onboarding working after releases.

## Your New Users Are Not Devs They Are Agents

_AI agent onboarding and developer journey testing_

Apostl runs selected public SDK, API, and documentation journeys in clean environments, records where they stop, and returns evidence your team can reproduce.

### How does Apostl test AI-agent developer onboarding?

_Direct answer_

Apostl starts one public SDK, API, quickstart, or documentation journey in a clean environment and asks an AI agent to reach a defined observable outcome using the available guide and tools. The run records commands, responses, elapsed steps, blockers, and the acceptance condition required to reproduce the result. Setup, a green syntax check, or an HTTP 200 is not treated as success unless the target outcome is observed. Apostl separates documentation, SDK, authentication, product, external-dependency, and environment failures, then returns the evidence and a bounded next action. Runs state their scope and known limitations; they do not use private credentials, real wallet material, or unsupported assumptions to force a pass. See the public API contract , review the dated rankings and methodology in Agent Arena , or watch the Polymarket journey recording . A free audit begins with one eligible public URL and sends its result when the run finishes.

- [public API contract](/developers)
- [Agent Arena](/arena)
- [Polymarket journey recording](https://youtu.be/1Lkjm3OUM4A)

### Polymarket, tested by an agent

_Can Agent Use It?_

One real task. Public docs only. Every step recorded.

- [Watch on YouTube](https://youtu.be/1Lkjm3OUM4A)

### Agents don't ask for help They switch to your competitor

_Why this matters now_

When developers hit broken docs, they ask for help. They open issues, message your community, and give you a chance to fix what failed.

Agents don't. They follow your docs, fail silently, and move on to the API, library, or protocol whose quickstart works.

You lose the developer and never know why.

- Opens a GitHub issue
- Messages your community
- Says nothing
- Switches to another API, lib, or protocol

### See where agent trust breaks

_The solution_

Apostl continuously follows your quickstarts, runs the examples, checks API calls, and identifies the exact step where the guide breaks and trust is lost.

- What failed the exact journey and step that broke
- Why it failed recorded evidence, with any inference labeled
- How to fix it a focused proposed change when the evidence supports one

### Brilliant Developer Experience after any Pull Request

_Continuous verification, native to GitHub_

When a pull request changes docs, SDKs, examples, authentication, or APIs, Apostl reruns the affected onboarding journey and reports the result before merge.

The quickstart still uses the previous authentication parameter. The clean onboarding run stopped before the first API response.

- 01 Change A pull request or push updates your docs, SDK, examples, authentication, or API.
- 02 Replay Apostl reruns the affected onboarding journey in a clean environment, the way a new developer or agent would.
- 03 Decide A pass/fail status check and evidence-backed comment appear in the pull request before merge.
- 04 Fix When the correction is clear, Apostl opens a focused pull request with the proposed change.

`docs/quickstart.mdx`
`sdk/auth.ts`

### Built by TON onboarding leaders

_The team_

Apostl is built by operators with first-hand experience in Web3 developer onboarding, documentation, integrations, and ecosystem growth.

- Built developer onboarding programs at TON Foundation
- Led onboarding, documentation, and integration work
- Worked across multiple public SDK journeys
- Led developer relations programs at TON Foundation
- Organized developer hackathons and activation programs
- Created developer education and onboarding materials

- [LinkedIn](https://www.linkedin.com/in/krutovoy/)
- [LinkedIn](https://www.linkedin.com/in/vladimir-alefman/)

### Get your agent onboarding measured

_Get started_

Send your email and one public docs or quickstart URL. Apostl will queue a bounded developer-onboarding run, record the terminal outcome or blocker, and email the available evidence when processing finishes.

Form fields:
- Docs or quickstart URL
- Where to send the report

### Get demo access and a guided setup

_15-minute personal onboarding_

We'll give you access to the Apostl demo and personally set it up around one of your developer journeys.

Calendar not loading? Open Cal.com →

- [Open Cal.com →](https://cal.com/apostl/15min)

---

Source: https://apostl.dev/services.md
Canonical HTML: https://apostl.dev/services

# Developer Activation and Agent Experience Services | Apostl

Test SDK, API, and documentation journeys, expose exact onboarding blockers, and retest developer and AI-agent activation as releases change.

## Predictable activation for developers and agents

See where developers and their agents stop. Then retest selected critical journeys as the product changes.

- [Run a free audit](/#start)

### What does Apostl improve in developer and AI-agent onboarding?

_Direct answer_

Apostl measures one defined developer journey, identifies where a person or AI agent stops, and turns the evidence into a scoped improvement plan. The Activation Sprint establishes a baseline across selected public documentation, SDK, API, authentication, and test-environment steps. Developer Journey Uptime then reruns agreed critical paths as releases change them. The Ecosystem Growth Program addresses the surrounding acquisition, qualification, and activation process with milestones set for the engagement, while Agent Experience QA reports a selected journey inside the pull-request workflow. Each service starts with an observable outcome and named boundaries; it does not guarantee every integration, every repository, or a universal conversion result. Findings distinguish documentation, SDK, product, credential, external-dependency, and environment blockers so the responsible team can review the next action. Use the free public audit for one eligible quickstart, inspect the public technical contract , or review the four service scopes below before discussing a private or authenticated journey.

- [free public audit](/#start)
- [public technical contract](/developers)

### Four products, one path to first success

Start with the sprint, hold the result with uptime, grow the funnel over a year, or put documentation QA into your CI.

### Developer & Agent Activation Sprint

Evidence showing where selected developers and AI agents finish onboarding, where they stop, and what the team can improve next.

### Developer Journey Uptime

Ship SDK, API, and documentation releases without breaking activation. Regressions surface before developers and partners notice them.

### Developer Ecosystem Growth Program

A measured program for reaching a defined cohort, qualifying relevant teams, and improving their path to active ecosystem building.

### Agent Experience QA in GitHub CI

Selected documentation regressions are reported in the pull request with the journey step and evidence needed for review.

### Developer & Agent Activation Sprint

_Product 01 · 1 month_

A predictable flow of developers and AI agents who complete onboarding on their own, successfully integrate the product, and start creating value in your ecosystem.

### An in-depth DevEx audit tied to business metrics

We audit the developer and agent journey against the target metrics your leadership already tracks.

### The audit becomes an onboarding process

Findings are transformed into a streamlined onboarding flow, not a backlog of observations.

### An outcome a CEO can read

The result is presented in business terms rather than as a list of technical findings.

### Weeks instead of engineer-months

You get the measured state of your onboarding in weeks and keep your engineer-months for the roadmap.

### Only what is worth a sprint

Only items worth a sprint make it into the report. Engineers fix problems instead of sorting through someone else's list.

### Founder-backed, not a one-off pilot

The work is led by founders with first-hand experience in Web3 developer onboarding, integrations, and ecosystem programs.

### Your team keeps it running

An expert inside your team is trained on our frameworks and can maintain everything we improved.

- 60–90 minutes for the kickoff
- Access to documentation, the SDK, and the test environment
- One technical meeting of 1–2 hours per week (your DRI)
- Review and approval of proposed changes (your DRI)
- Engineering time only for issues inside the core product or the SDK

- [Start the activation sprint](https://cal.com/apostl/15min)

### Developer Journey Uptime

_Product 02 · Monthly subscription_

Retest agreed SDK, API, and documentation paths as releases change them. When a selected journey regresses, the run reports the affected step and evidence for review.

### Monitor conversion to successful integration

Compare the share of developers who reach a working integration as selected release paths change.

### Regressions detected by synthetic DevEx tests

Critical journeys are executed continuously instead of being reviewed by hand.

### Confidence in SDK, API, and documentation releases

You ship knowing the paths developers depend on still work.

### Fewer support escalations and less firefighting

Support and engineering stop absorbing the cost of a journey that quietly broke.

### Protection against silent churn

Developers who would have left without telling you are caught by a test, not by a lost quarter.

### Constant evidence that developer onboarding works

Every month ends with proof of the current state instead of an opinion about it.

### Release pace stops being a risk factor

You can roll out updates more frequently without losing new developers as a result.

### No time wasted on repeating other people's errors

Each error arrives with the context in which it is bound to happen again.

- Complete the Developer & Agent Activation Sprint
- Define the success criteria
- Provide test access and credentials
- Assign one technical owner (your DRI)
- Join short monthly reviews
- Approve proposed fixes
- Involve engineers only for product or SDK issues

- [Keep my journeys up](https://cal.com/apostl/15min)

### Turn ecosystem attention into active builders

_Product 03 · 12 months_

A measured program for reaching a defined cohort, qualifying relevant teams, and improving their path to active ecosystem building.

Led by operators with first-hand Layer 1 developer-onboarding experience

Not by a technical writer who has never managed it. A 12-month program, with scope and milestones set on the first call.

- [Plan the growth program](https://cal.com/apostl/15min)

### Agent experience QA for full documentation in GitHub CI

_Product 04 · Credits_

Reduce the risk that a critical partner launch stalls over outdated documentation, and give engineering reproducible evidence before the same support question repeats.

Get the first report free, based on your connected documentation repository and 30 days of commit activity.

- Stop a documentation regression at the pull request The break is caught in CI, before it reaches a developer.
- Stop losing weeks of integration to a snippet that cannot build Every example is executed the way a developer would run it.
- Catch syntax errors before the first developer session The tested example must build before the check passes.
- Fixes enter a sprint the week they are found Each finding arrives with the evidence needed to act on it.
- Share your email
- Learn one new tool
- Give access to the documentation repository

- [Get the first report free](https://cal.com/apostl/15min)

### What to know before the first call

### Choose the right starting point

Start with the Developer & Agent Activation Sprint when you need the measured state of onboarding and a plan your team can execute. Add Developer Journey Uptime once that state exists and selected release paths need continued checks. The GitHub CI check provides pull-request evidence, and the first report is free.

### How the four products fit together

The sprint sets the baseline and turns it into an onboarding process. Uptime retests agreed paths as the SDK, API, and documentation change. The growth program develops the top of the funnel over a year. The CI check evaluates selected documentation journeys in repositories included in the engagement.

### What your team actually spends

A 60–90 minute kickoff, access to documentation, the SDK, and a test environment, and one technical meeting of 1–2 hours per week with your DRI. Your engineers are involved only for issues inside the core product or the SDK, not for coordination.

### Beyond Web3

Yes. We work with B2B products that developers adopt through technical integrations. That includes Web3 and fintech teams. We also work with payment infrastructure and developer platforms where adoption depends on a working API or SDK.

### Great agent experience starts with one journey that works

- [Talk to us](https://cal.com/apostl/15min)

---

Source: https://apostl.dev/pulse.md
Canonical HTML: https://apostl.dev/pulse

# How many AI agents use your website?

Pulse estimates the AI agent traffic already reaching your public site. The dashboard gives you one live number, then shows the pages those agents use. Active means seen in the last 30-minute window; Top Pages covers 30-day estimated unique agents and total requests.

Pulse uses heuristic classification. It cannot prove which person, company, or exact model made a request.

## What does Apostl Pulse measure?

Apostl Pulse estimates how much AI-agent traffic reaches a public website and which canonical pages those requests use. A server-side middleware observes eligible public `GET` and `HEAD` responses, removes query strings, fragments, URL credentials, request bodies, cookies, and authorization headers, then sends the request IP, User-Agent, canonical `origin + pathname`, method, status, and duration to Apostl. The platform applies heuristic classification and reports active agents in a 30-minute window plus 30-day page aggregates. That output is an estimate: Pulse cannot identify a person or company, prove which exact model made a request, or treat one request as a qualified lead. An agent may create and verify a setup before a person claims the project, but the server API key must stay outside source control and browser code. Inspect the [MIT-licensed SDK](https://github.com/apostl-dev/pulse-sdk), the [setup flow](#install), and the [privacy notice](https://apostl.dev/privacy) for the implementation and data boundaries.

## Measure the request, then inspect the page

Pulse follows the benchmark-first instinct behind Tempo StableBench: define a behavior and retain inspectable evidence. No StableBench result or implementation detail is imported into Pulse. Source: https://tempo.xyz/developers/blog/introducing-stable-bench-v1

- Estimated active agents now
- Top public pages by estimated unique agents
- Total agent requests per page
- Server-side evidence for HTML, Markdown, `llms.txt`, and other public files

## Page identity stays useful

Every visit is stored as canonical `origin + pathname`. Query strings, fragments, and URL credentials are removed, so `/docs/quickstart?token=...#install` becomes `/docs/quickstart`. The canonical form rolls query variants into one page row.

By default, Pulse counts public GET and HEAD requests with statuses 2xx through 4xx. Assets, health checks, auth and private routes, and mutations stay out of the metric.

## What the server sends

Each eligible event includes the request IP address, User-Agent, canonical page URL and path, method, status, and duration. Request bodies, cookies, authorization headers, query strings, and fragments are not sent. The platform owns classification rules, so there is no service type to maintain in application code.

## Start safely with the agent helper {#agent-setup}

An agent can create the setup, install the middleware, and prove a real deployment before a person signs in. The unclaimed setup lasts seven days. Before starting, the agent needs a public HTTPS origin it is authorized to deploy, access to that server's code and secret runtime, and permission to deploy it.

```sh
npx skills add apostl-dev/apostl-skills --skill agent-traffic-analytics -g -y
```

Open the installed `agent-traffic-analytics/SKILL.md`, move to that skill directory, replace the intentionally invalid origin below, and run its setup helper:

```sh
python3 scripts/pulse_setup.py start \
  --origin "https://replace-me.invalid" \
  --verification-path /llms.txt \
  --project-name "My public site" \
  --agent-name "Codex"
```

The helper intentionally rejects `replace-me.invalid`, `example.com`, and other reserved documentation domains before any API mutation. Replace it with the exact public origin where you can deploy Pulse. `example.com` is a reserved documentation domain, not an end-to-end demo target.

The helper stores the server-only API key and opaque setup token in an owner-only `0600` file, then prints only non-secret metadata. Do not use raw curl for the first setup: its JSON response contains the credentials once and can be copied into a tool transcript or terminal log.

## Install one server middleware {#install}

```sh
npm install @apostl-dev/pulse-sdk
```

```ts
import { createPulse } from '@apostl-dev/pulse-sdk';
import { pulseExpressMiddleware } from '@apostl-dev/pulse-sdk/express';

const pulse = createPulse({
  endpoint: 'https://ingest.apostl.dev',
  apiKey: process.env.APOSTL_PULSE_API_KEY,
});

app.use(pulseExpressMiddleware(pulse));
```

The middleware sends events to https://ingest.apostl.dev. It includes the IP address and User-Agent from the server request, then strips query parameters before the event leaves your process.

## Verify, then claim

After deployment, run the same helper with the absolute credentials path printed during setup:

```sh
python3 scripts/pulse_setup.py verify --credentials /absolute/path/to/pulse.json
```

The helper calls the saved `verify_url` with the setup token as a Bearer credential. Apostl fetches the real public verification URL with a signed challenge. The signed response alone does not unlock the project: a claim link appears only after Apostl also receives that request as a real event.

The claim link contains no API key and works once. A person finishes with Google, GitHub, or an email magic link. The ingest API key remains active after claim. If the origin is already connected, the setup API refuses a second project instead of taking over the domain.

Open Apostl Platform at https://platform.apostl.dev, inspect the complete MIT-licensed SDK at https://github.com/apostl-dev/pulse-sdk, or read the exact setup and verify schemas in the [public OpenAPI contract](https://apostl.dev/openapi.json).

---

Source: https://apostl.dev/developers.md
Canonical HTML: https://apostl.dev/developers

# Build with Apostl

Apostl publishes its public integration surface for developers and AI agents. Start with the OpenAPI contract for exact request and response schemas, or use the Markdown index when you need product context before choosing an endpoint.

The public landing API accepts agent-readiness audit requests and Arena proof-pack requests. Apostl Pulse has a separate agent-first setup flow for installing traffic measurement on a public website.

## What can an agent discover and call on apostl.dev?

An agent can discover Apostl through the [RFC 9727 API catalog](https://apostl.dev/.well-known/api-catalog), inspect exact operations in the [OpenAPI 3.1 contract](https://apostl.dev/openapi.json), and read the site through Markdown alternates or [llms.txt](https://apostl.dev/llms.txt). The public landing API exposes health and browser-configuration reads, a submission endpoint for one public agent-readiness journey, and an Arena endpoint for requesting the proof pack behind a published benchmark finding. Mutating requests use JSON, typed schemas, stable error codes, human-readable messages, and resolution hints. The audit endpoint accepts only a public HTTP or HTTPS quickstart URL plus a report-delivery email; it may also require a Turnstile token when abuse protection is enabled. The public flow is not a credential transport. Do not send passwords, private repository URLs, API secrets, wallet material, session cookies, or unredacted customer data. For traffic measurement, follow the separate [Pulse setup guide](https://apostl.dev/pulse.md) and keep its server API key outside browser bundles and source control.

## Machine-readable entry points

- [Apostl OpenAPI 3.1 specification](https://apostl.dev/openapi.json)
- [Apostl RFC 9727 API catalog](https://apostl.dev/.well-known/api-catalog)
- [Apostl llms.txt index](https://apostl.dev/llms.txt)
- [Apostl full Markdown corpus](https://apostl.dev/llms-full.txt)
- [Apostl XML sitemap](https://apostl.dev/sitemap.xml)
- [Apostl Pulse setup guide](https://apostl.dev/pulse.md)

Each operation in the OpenAPI file has a unique `operationId`, a description, typed request fields, typed responses, and structured errors. HTML pages that have a Markdown equivalent also negotiate `text/markdown` through the `Accept` request header.

## When an agent should use Apostl

- Use Apostl when a public SDK, API, quickstart, or documentation journey needs to be executed in a clean environment and checked for the exact blocker.
- Use Apostl Pulse when a team needs privacy-bounded estimates of AI agent traffic to public website pages.
- Use the audit endpoint when you have a public HTTP or HTTPS quickstart URL and an email address that can receive the evidence report.
- Use the Arena proof-pack endpoint when a published benchmark entry has a finding that needs its commands, trace, likely owner, and acceptance test.

Do not send Apostl passwords, wallet secrets, private repository URLs, session cookies, or other credentials through the public landing API. Contact the founders before testing a private or authenticated journey.

## Inspect the public API

```sh
curl -sS https://apostl.dev/openapi.json
```

```sh
curl -sS -H 'accept: application/linkset+json' https://apostl.dev/.well-known/api-catalog
```

```sh
curl -sS https://apostl.dev/health
```

The landing API requires JSON request bodies for mutations. Errors keep the stable `error` code used by existing clients and add a human-readable `message` plus a `resolution` hint. Rate-limited responses also include `Retry-After` and `retry_after_seconds`.

## Start an agent-readiness audit

```sh
curl -X POST https://apostl.dev/api/quickstart-submissions \
  -H 'accept: application/json' \
  -H 'content-type: application/json' \
  -d '{"email":"developer@example.com","quickstart_url":"https://docs.example.com/quickstart"}'
```

The URL must be public HTTP or HTTPS. The endpoint may require a Cloudflare Turnstile token when abuse protection is enabled. A successful request returns HTTP 202 with the run status and, when available, the report URL.

## Install Apostl Pulse

Pulse uses an accountless setup flow on Apostl Platform. Start with the public helper so its one-time API key and setup token go directly into an owner-only file instead of a terminal or tool transcript.

```sh
npx skills add apostl-dev/apostl-skills --skill agent-traffic-analytics -g -y
```

Follow the complete [Apostl Pulse setup and verification guide](https://apostl.dev/pulse.md), inspect the [MIT-licensed Pulse SDK](https://github.com/apostl-dev/pulse-sdk), or open the [Agent Traffic Analytics skill](https://github.com/apostl-dev/apostl-skills/tree/main/skills/agent-traffic-analytics). The OpenAPI file includes the exact cross-origin setup and verify schemas served by `platform.apostl.dev`.

## Support and security

For API questions, responsible security reports, private-journey scoping, or a missing schema, email [founders@apostl.dev](https://apostl.dev/contact). Include the endpoint, HTTP status, stable error code, and a redacted request example. Never send credentials or unredacted customer data.

---

Source: https://apostl.dev/about.md
Canonical HTML: https://apostl.dev/about

# Developer journeys should work when nobody is watching

Apostl helps developer-product teams find and fix the point where a developer or AI agent stops making progress. We run public SDK, API, and documentation journeys in clean environments, preserve the evidence, and turn the failure into a concrete next action.

The company is built around a simple operating belief: a plausible guide, a green build, or an HTTP 200 is not proof that a new user reached a working result.

## What counts as evidence in an Apostl developer-journey test?

Apostl treats a developer journey as verified only when the defined terminal outcome is observed in the stated environment. A run begins with one bounded public SDK, API, quickstart, or documentation task and records the environment, commands, responses, elapsed steps, blockers, and acceptance criteria needed to review the result. Static syntax checks remain labeled as static evidence; successful setup or an HTTP 200 does not become runtime proof unless it satisfies the task's stop condition. A blocked journey stays blocked when a credential, external dependency, sandbox resource, or product decision is missing. Reports separate observed behavior from product claims and from analyst inference, and they state what the run did not test. Apostl does not use private credentials, real wallet material, or unsupported assumptions to force a passing result. The [developer portal](https://apostl.dev/developers) exposes the public contract, while [Agent Arena](https://apostl.dev/arena) shows how dated benchmark outcomes and frictions are presented for review.

## What Apostl does

Apostl works with Web3, fintech, payment infrastructure, and developer-platform teams whose activation depends on a technical integration. The product and services cover agent-readiness audits, continuous developer-journey validation, evidence reports, Agent Arena benchmarks, and privacy-bounded analytics for public AI agent traffic.

The work begins with one bounded journey and one observable outcome. Apostl records the environment, commands, responses, blockers, and acceptance criteria needed to reproduce the result. Private credentials, real wallet material, and unsupported claims are not used to force a passing report.

## Evidence before opinions

We separate what was observed from what was claimed or inferred. A static syntax check is labeled as static evidence. A runtime result is labeled with the environment and outcome that actually ran. A blocked journey remains blocked until the missing credential, external dependency, or product decision is resolved.

That standard is designed for AI agents as well as people. Agents need predictable URLs, machine-readable contracts, structured errors, and unambiguous terminal states. Apostl publishes its own OpenAPI file, Markdown pages, `llms.txt`, sitemap, and public developer portal so its interface can be inspected the same way.

## The founders

Apostl is led by Roman Krutovyi and Vladimir Alefman. Their work combines developer ecosystem growth, product positioning, automation, SDK and documentation operations, and hands-on activation programs. The public team profiles and professional links are available on the [Apostl homepage](https://apostl.dev/#team).

The company operates as a remote team and works with developer-infrastructure organizations across markets. For commercial, technical, or partnership questions, use the [contact page](https://apostl.dev/contact). Apostl does not publish a postal office or telephone number until those details are approved as official company contact information.

## Verify Apostl

Read the [developer portal](https://apostl.dev/developers), inspect the [OpenAPI specification](https://apostl.dev/openapi.json), or request a bounded audit using a public quickstart URL. The [privacy notice](https://apostl.dev/privacy) explains what the public site and submission flows collect and which service providers participate in those flows.

---

Source: https://apostl.dev/contact.md
Canonical HTML: https://apostl.dev/contact

# Talk to the people building Apostl

Email [founders@apostl.dev](mailto:founders@apostl.dev) for developer-journey audits, Apostl Pulse, Agent Arena, technical partnerships, API questions, security reports, or privacy requests. Roman Krutovyi and Vladimir Alefman review this shared address.

You can also [book a 15-minute conversation](https://cal.com/apostl/15min) when a short live discussion is the fastest way to define the journey and the outcome that matters.

## What to include

- The public documentation, SDK, API, or product URL you want Apostl to inspect.
- The result a new developer or agent should reach, such as a testnet transaction, an authenticated API response, or an installed server integration.
- The environment and product version that should be treated as canonical.
- Any launch date, customer commitment, or release window that changes the urgency.

Do not email passwords, API keys, wallet seed phrases, private keys, session cookies, or production customer data. Apostl will ask for a safe, scoped credential path only when a private journey has been explicitly agreed.

## Technical support

For a public API problem, include the request URL, HTTP method, response status, stable `error` code, and a redacted example. The machine-readable contract is published at [apostl.dev/openapi.json](https://apostl.dev/openapi.json), and integration guidance lives in the [Apostl developer portal](https://apostl.dev/developers).

For Apostl Pulse, include the site origin, server framework, SDK version, and whether URL verification and the first real event succeeded. Never include the Pulse ingest API key or setup token.

## Privacy and security

Use the same founders address for access, correction, deletion, or other questions about information submitted through this site. The [privacy notice](https://apostl.dev/privacy) describes the current public-site data flow. For a security report, provide enough reproduction detail to identify the affected surface without including secrets or accessing data that is not yours.

## Company contact details

Apostl currently publishes email and scheduled video calls as its official contact channels. A postal business address and telephone number are not shown because they have not been approved as official public company details. The team works remotely with developer-infrastructure companies across markets.

---

Source: https://apostl.dev/privacy.md
Canonical HTML: https://apostl.dev/privacy

# Privacy on apostl.dev

This notice describes the public Apostl website, its audit and Arena submission forms, Apostl Pulse measurement on this domain, and links to external scheduling or platform services. Last updated: 25 August 2026.

Apostl designs these flows to collect the information needed to operate and improve a developer journey without asking for passwords, private keys, wallet seed phrases, session cookies, or private customer data.

## Information the site receives

When a browser or automated client requests a public page, the server can receive the IP address, User-Agent, requested path, HTTP method, response status, referral information, and timing data normally included in web requests. Apostl Pulse may classify eligible public `GET` and `HEAD` traffic heuristically and aggregate activity by canonical origin and pathname. Query strings, URL fragments, request bodies, cookies, and authorization headers are not included in Pulse events.

The free-audit form receives the email address and public quickstart URL you submit. It also sends operational metadata such as IP address, User-Agent, page URL, referrer, locale, platform, client time, and time zone. An Arena proof-pack request receives a work email plus the selected public benchmark entry and finding context. These fields are used to run the requested workflow, prevent abuse, deliver or follow up on the result, and diagnose failures.

## Analytics and service providers

The site loads Google Analytics for aggregate site and conversion measurement. Cloudflare Turnstile may process a challenge when form abuse protection is enabled. Cal.com processes scheduling information when you open or use the booking experience. Accepted audit requests are forwarded to Apostl Platform for execution. The server may send the founders a Telegram notification containing the submitted email, public URL or benchmark context, and run status so the team can operate the request.

These providers process information under their own terms and privacy practices. Following an external link, opening an embedded calendar, or completing a third-party authentication flow may allow that provider to set cookies or collect additional information outside apostl.dev.

## How Apostl uses information

Apostl uses submitted and request data to provide the requested audit or proof pack, secure and rate-limit public endpoints, communicate about the request, maintain service reliability, measure public product usage, and improve developer and agent onboarding. Apostl does not ask users to place secret credentials in public forms and does not publish submitter emails in public evidence reports.

Access to operational systems is limited to the team and service providers needed to run the workflow. No internet service can promise absolute security; report a suspected exposure to [founders@apostl.dev](mailto:founders@apostl.dev) and avoid sending the affected secret in the report.

## Your choices and requests

You can browse the public text and machine-readable files without submitting a form. You can avoid the embedded calendar by emailing Apostl directly. Browser controls and extensions may limit third-party analytics or cookies, although some abuse-protection or scheduling features may then be unavailable.

To ask what information Apostl holds about a submission, request correction or deletion, or raise another privacy question, email [founders@apostl.dev](mailto:founders@apostl.dev). Include enough context to locate the request, but do not send secrets or identity documents unless Apostl gives you a secure and necessary method.

## Scope and changes

This notice covers apostl.dev. Authenticated Apostl Platform features or customer contracts may include additional terms and controls. Apostl will update this page when the public data flow or its material service providers change, and the updated date at the top will identify the current version.

---

Source: https://apostl.dev/arena.md
Canonical HTML: https://apostl.dev/arena

# Web3 Agent Benchmark: Developer Journey Rankings

Agent Arena compares public Web3 developer journeys by asking an AI agent to reach a defined, observable result in a clean environment. The live page at https://apostl.dev/arena is server-rendered from the current reviewed `arena.v1` snapshot; this Markdown page explains how to interpret it without duplicating data that may change.

## How are Agent Arena results produced and ranked?

Apostl selects a public guide, starts a clean isolated environment, and gives the agent the tools and scoped test credentials a new integrator could reasonably use. Each category defines an observable stop condition, such as a verified testnet transaction, accepted order, or successful inference response. The run records the route, commands, responses, elapsed time, frictions, and whether a human interruption was required. A setup step or HTTP 200 is not counted as success unless the category's target outcome is observed. Reviewed successful outcomes rank ahead of blocked runs; ties then favor lower completion time, fewer distinct frictions, and lower normalized model cost. The live benchmark exposes its snapshot date, sample count, runner model, and methodology version beside the results. Read the current table at https://apostl.dev/arena or request a reproduction pack through https://apostl.dev/developers. Results describe the tested journey and environment, not every possible product configuration.

## Measurement contract

- **Guide selection:** public developer guidance is the primary source; private product knowledge is not assumed.
- **Execution:** runs use clean environments and bounded test credentials when the journey requires them.
- **Verification:** the category task defines the terminal outcome. Static syntax checks and intermediate HTTP responses are not terminal proof.
- **Ranking:** verified outcomes precede blocked runs, followed by time, unique frictions, and normalized model cost.
- **Limitations:** one sample describes one dated environment, guide version, runner, and task. It is not a universal product rating.

## Machine-readable sources

- [Live Agent Arena](https://apostl.dev/arena)
- [Apostl developer portal](https://apostl.dev/developers)
- [Apostl OpenAPI specification](https://apostl.dev/openapi.json)
- [Apostl API catalog](https://apostl.dev/.well-known/api-catalog)

---