GHAN— by singular Get started

Get started with GHAN

Register the app, read the gate result, wire the SDK, ship it in your own signed release, and either earn credits or spend them. A coding agent can do every step except shipping the release and authorising money, and those two are human on purpose.

Before you start

You need:

  1. A signed build — notarised on macOS, Authenticode-chained on Windows.
  2. A domain at least six months old.
  3. A download URL that serves the bundle id you are going to declare.
  4. An email address you can answer a challenge on.

If any of those is missing, the gate will say so precisely, with a date where the failure is time-based.

For a human

1. Register

register_app {
  name: "Your App",
  platform: "mac",
  bundle_id: "com.you.yourapp",
  domain: "yourapp.com",
  download_url: "https://yourapp.com/download/YourApp.dmg",
  contact_email: "[email protected]"
}

Returns an app_id and an api_key, with status pending.

2. Read your score

get_score { app_id }

Gate booleans, reputation breakdown, and reason codes for anything that failed.

3. Wire the SDK

npm install @ghan/sdk
npx @ghan/sdk init     # writes the wiring, leaves a reviewable diff
await ghan.init({ appId: process.env.GHAN_APP_ID, consent: settings.analyticsConsent })
await ghan.slot('first_success')

Full surface: the SDK quickstart.

4. Ship it

In your own signed release. This is one of the two deliberately human moments — GHAN cannot push code into your application and would not want the ability.

5. Earn, or spend

Serving placements accumulates credits. To buy installs instead:

top_up { app_id, amount_cents }        # Stripe Checkout, or x402 for an agent
create_campaign { app_id, categories, daily_budget_cents }

6. Verify everything

get_stats  { app_id, period: "last_30_days" }
get_ledger { app_id, from, to }

Take any billed line, resolve its event chain, and verify the receiving signature against your own registered public key. See transparency.

For an agent

Point it at the MCP server. The whole sequence:

get_rate_card {}                  # public — decide whether this is worth doing
register_app { ... }              # -> app_id, api_key
get_score { app_id }              # -> reason codes, act on them
get_integration_guide {}          # -> wire the SDK, open a PR
  ── human ships the release ──
top_up { app_id, amount_cents }   # -> 402, or a checkout URL for a human
create_campaign { ... }
get_stats / get_ledger            # -> verify all of the above

The MCP server card is at [/mcp/server-card.json](/mcp/server-card.json), discovered through [/.well-known/ai-catalog.json](/.well-known/ai-catalog.json).

Questions people ask about this

How long does onboarding take?

The integration is minutes. The gate is automated and usually completes in under an hour, except for the email challenge which waits on you. The real constraint is your own release cycle, because the SDK has to arrive in a build you sign and ship yourself.

What do I need before I start?

A signed and notarised macOS build or an Authenticode-signed Windows build, a domain you have owned for at least six months, a download URL that serves the bundle identifier you declare, and an email address you can answer a challenge on. That is the whole list.

Do I need to talk to anyone?

No. There is no sales process and no onboarding call. The rate card is published, the gate is automated, and the entire flow is available over MCP.

What if I fail the gate?

You get machine-readable reason codes rather than a rejection email, with eligibility dates where the failure is time-based. Fix what is fixable and the gate re-runs automatically - nothing has to be resubmitted by hand.

Machine-readable versions of this page: markdown · llms.txt · llms-full.txt · OpenAPI · AI catalog