Guides

Apply to publish a public capability

Lipafy has two kinds of capabilities:

  • Private — registered through the dashboard at /capabilities/new, default status draft, only callable by your account. No review.
  • Public — submitted through the application form, reviewed by Lipafy, and on approval listed in the registry where any agent can discover and call them.

This page is about the public path.

Why apply for a public listing

A public capability shows up in GET /v1/capabilities (the global registry endpoint used by agents and dashboards) and is callable by anyone with a funded Lipafy wallet. You get paid in KES at the end of each settlement period (Settlements) minus the agreed revenue share. No new endpoints or integration on your side — you just keep your existing HTTPS API running.

If you only want internal capabilities (e.g. for your own company’s agent), use the private route instead — it skips review entirely.

The form

Submit at /capabilities/apply. No Lipafy account required.

app_name
stringRequired

Public name shown to agents and reviewers, e.g. “Local Lunch Kenya”.

proposed_slug
stringRequired

Globally unique. Convention: <domain>.<brand>.<action> — e.g. eats.local-lunch.order. Lowercase, letters / numbers / dots / dashes / underscores only. See slug conventions.

description
stringRequired

One paragraph an agent can read to decide if the capability fits its task. 20–2000 chars. Plain language beats jargon — reviewers and downstream agents both prefer “Place a lunch order from local restaurants in Nairobi, returns order ID and ETA” over “POST endpoint with order semantics”.

endpoint_url
string (https URL)Required

Your upstream API base. Lipafy forwards POST /gateway/<slug>/<sub-path> calls to <endpoint_url>/<sub-path>. Use a versioned base path you’re comfortable keeping stable: https://api.your-service.example/v1.

price_amount
integerRequired

Whole units of the currency. 50 means 50 KES per call.

price_currency
string (ISO 4217)

Defaults to KES. Other currencies are accepted but settlement is currently KES-only.

logo_url
string (https URL)

Hosted logo image. Used in the public registry review. Square images render best (48–256 px). No file upload — paste a URL you already host.

website_url
string (https URL)

Your marketing or product page. Helps reviewers verify legitimacy.

contact_name
stringRequired

Person responsible for the integration. Used for approval correspondence.

contact_email
string (email)Required

We email this address with the approval / rejection decision and to coordinate upstream auth setup post-approval.

Don’t send secrets in the form. The application is public-facing and the response body is not encrypted. If your upstream needs a bearer token / API key / basic auth, we’ll provision it with you privately after approval (via a one-off out-of-band channel — usually a Signal or PGP email exchange).

What happens next

1

You submit

The form POSTs to /v1/capability-applications. We rate-limit by IP. You’ll see a “Application received” confirmation.

2

Lipafy reviews the submission

Typically within 1–3 business days. The review checks:

  • The endpoint resolves and returns a sensible response (we may hit it from a test account).
  • The slug isn’t taken and follows convention.
  • The description is honest about what the capability does.
  • The price is reasonable for the underlying cost.
  • The applicant has the right to monetize this service (you wrote it, or you have permission).
3

You hear back by email

  • Approved — a capability row is created with status='active' and your endpoint becomes immediately discoverable in GET /v1/capabilities. We follow up to coordinate upstream auth.
  • Rejected — you get the reviewer’s notes. Common reasons: slug conflict (pick a new one), description too vague, endpoint unreachable, pricing mismatch. You can resubmit after addressing them.
4

(Approved only) Provision upstream auth

For private capabilities you configured this at registration time. For public ones, do not put secrets in the application form; Lipafy coordinates credential setup separately and stores the credential encrypted at rest. Until that’s done, the capability is callable but unauthenticated to your upstream — so most providers wait to mark the capability fully live until this step completes.

Verifying approval

Once approved, your slug shows up in:

$curl https://api.lipafy.xyz/v1/capabilities | jq '.capabilities[] | select(.slug == "eats.local-lunch.order")'
1{
2  "id": "...",
3  "slug": "eats.local-lunch.order",
4  "name": "Local Lunch Kenya",
5  "description": "...",
6  "price_amount": "50",
7  "price_currency": "KES",
8  "status": "active",
9  "provider_type": "passthrough"
10}

The provider_config (including any auth that’s been provisioned) is not returned — only owner-scoped reads see it. You can verify on your end with a test call from an agent or curl to /gateway/<slug>.

After it’s live

  • Track settled calls through your wallet transactions and settlement records.
  • Monitor request volume from the dashboard overview and GET /v1/usage/breakdown.
  • If you need to change pricing, description, or status, PATCH /v1/capabilities/:id (you’ll be set as the owner so this works). See Capabilities API.
  • To take it offline: delete it (soft-delete sets status='disabled', hides it from the public list but keeps historical receipts intact).

FAQ

No — applications are immutable once submitted. If you spot a typo, contact the reviewer (your contact email gets a confirmation reply they can respond to). For larger changes, ask them to reject the current one and resubmit.

Reviewers reject the application with a note. Pick a more specific slug (eats.local-lunch.nairobi.order instead of eats.local-lunch.order) and resubmit.

Yes. Different slugs can point at the same upstream URL with different paths or pricing — useful when you have e.g. a discounted bulk endpoint vs. a single-order endpoint.

Defaults to 0% (you keep everything; Lipafy charges the caller directly for facilitator services in a different lane). Custom revenue shares are negotiable for high-volume providers — bring it up with the reviewer.

Yes — sign in to the dashboard and use /capabilities/new. That path skips review, creates a draft capability only you can call, and is the right way to test your integration end-to-end before applying for public listing.