ArkAPI: a pay-per-call API gateway with Lightning and native Ark payments, built on Bark and live on Signet

Hey all! I wanted to share a project I’ve been building.

ArkAPI is a pay-per-call API gateway live on Signet where sessions are funded via Bark. Both Lightning invoices and native Ark payments work for activating sessions.

This was a genuinely fun build. The Bark integration was way smoother than I expected going in. Being able to accept Lightning payments without running my own node, and having native Ark payments work alongside that, made the whole payment layer surprisingly simple to wire up. The barkd REST API is clean and just does what you’d expect. Huge props to the Second team for making this so approachable for developers.

You can see the full session funding and API call flow on the landing page, or check out the interactive funding page at arkapi.dev/fund/ and the full API docs at arkapi.dev/docs/

There are currently 24 endpoints covering:

  • Security: DNS, WHOIS, SSL, headers audit, CVE lookup, AXFR check
  • OSINT: domain intel, IP geolocation, email auth
  • Utility: weather, BTC price, QR codes, screenshots, domain availability
  • AI: chat, translation, image generation

Full pricing in the OpenAPI spec at:
arkapi.dev/openapi.json

The API is also designed for agent access. There’s an OpenAPI spec, an llms.txt file, and a .well-known/arkapi.json manifest so agents can discover endpoints and pricing programmatically. The idea is that an agent with a funded session token can call any endpoint without human intervention — no API key provisioning, no OAuth, just a bearer token backed by sats.

The backend is a Go service in Docker talking to barkd on localhost:3000 for all payment operations. MySQL handles sessions and billing. Apache and Cloudflare sit in front. Everything runs on a single VPS. A background poller checks for Lightning invoice payments and also monitors for incoming VTXOs to handle native Ark funding. Both rails activate the same session.

A few questions for the team:

  • For native Ark payments, is polling wallet state the right approach today, or is there a cleaner way to detect incoming VTXOs tied to a specific purpose?
  • Any plans for barkd webhook or callback support when payments arrive?
  • For a merchant wallet receiving many small payments, is there anything I should be aware of around VTXO refresh timing or wallet maintenance?
  • Once Bark goes mainnet, is there anything I should prepare for beyond changing the ASP URL and network settings?

If anyone wants to try it out, I’d really appreciate the testing and feedback. You can fund a session from arkapi.dev/fund/ or via curl. You’ll need Signet sats from the faucet at signet.2nd.dev to fund your Bark wallet, then pay via Lightning invoice or send directly to the Ark address. Once your session is active, all 24 endpoints are available to hit. Let me know if anything breaks or feels off.

If this is useful as a reference implementation for other developers building on Bark, I’d be happy to see it linked from docs or examples.

Happy to go into more detail on any part of the integration. Would love feedback from the team and the community on anything I should be doing differently.

Cheers,
PiHiker

Quick update after running ArkAPI on Signet for a bit longer.

Things have been working well overall, and I’ve kept building on top of the original launch. ArkAPI is still live on Signet and I’ve continued exercising the paid session flow across the API surface with both Lightning and native Ark funding.

Since the original post, I’ve added a few more APIs and improved some of the existing ones. I’ve been spending a lot of time on the small things that make it feel more usable in practice: tightening handlers, improving docs and landing pages, expanding the catalog, and making some of the responses more useful for agents out of the box.

One thing I did run into was on the Bark side. I first noticed it because some Lightning sends were getting stuck in pending instead of settling, while Ark sends from the same wallet were going through normally. In the Bark logs this showed up as thread ‘tokio-runtime-worker’ panicked at server-rpc/src/convert.rs:369:26: called Option::unwrap() on a None value. I started on the tagged release build, but for my deployment I ended up moving to a newer nightly source version and rebuilding Bark from commit 4962bd70f568dedc30e622406a97067d4c43f800. Since making that change, things have been stable.

After switching to that newer Bark build:

  • Lightning sends started clearing normally again
  • Ark session activation and funding kept working
  • the wallet maintenance flow became much more stable

So the short version is: the project is working, I’m still actively building on it, and in my case the nightly Bark build ended up being the right move for this Signet deployment.

I wanted to mention it in case anyone else building on Bark and Signet runs into something similar. In my case, moving to a newer commit solved it.

Any feedback is welcome.