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

Integrations
1

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

3 Likes
2

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.

4 Likes
3

@PiHiker This is amazing!

Just tried it and works great!

Some feedback:

  1. Maybe add copy to clipboard (example curl command) functionality when I click in one the of cards here: ArkAPI | Anonymous Pay-per-call APIs for Agents and Developers
  2. Following best practices, shouldn’t Bitcoin News API | ArkAPI be a GET and the limit param a query param?
  3. I can click in some API cards, others I can’t.
3 Likes
4

Answering your questions:

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? Polling is the right approach for now.

Any plans for barkd webhook or callback support when payments arrive? We are working on this

For a merchant wallet receiving many small payments, is there anything I should be aware of around VTXO refresh timing or wallet maintenance? Your database will grow a lot in size. For the VTXO refresh timing you can play with vtxo_refresh_expiry_threshold config in bark, but the default behaviour should be fine.

Once Bark goes mainnet, is there anything I should prepare for beyond changing the ASP URL and network settings? You will need to create a new bark wallet with the new params/settings

3 Likes
5

@psycarlo I really appreciate you testing and providing feedback, thank you so much!

I just pushed a few improvements, and they’re live now:

  • bitcoin-news now supports GET with ?limit= instead of requiring a JSON body
  • the homepage cards now have a Copy curl action
  • the dedicated landing pages also have Copy curl buttons now
  • the card-click inconsistency should be better now too. That was mostly because some endpoints already had dedicated landing pages and others did not yet. The ones without their own page now link to the docs instead.

That was great feedback. The little UX/details stuff is exactly the kind of thing I’m trying to keep tightening as I keep building this out.

If you notice anything else that feels off or inconsistent, definitely let me know.

Thanks again!

2 Likes
6

Quick update: ArkAPI now has over 25 endpoints and I just posted a walkthrough on Stacker News showing off the Domain Intel endpoint. Ran arkapi.dev through its own API and walked through the full response.

The post gives Second and barkd a shoutout since the whole payment layer runs on your stack. No separate Lightning node, just barkd in Docker handling both rails. Figured it was worth getting it in front of the broader Bitcoin community.

Hopefully I get some new testers out of it. :slight_smile:

2 Likes
7

Upgraded Bark to 0.1.1 this morning. Was still on an older snapshot so this was a pretty decent jump , good excuse to rebuild and re-test the full funding flow.

Re-ran the whole path after the upgrade: create funded session, verify unpaid calls get blocked, pay the invoice from a second Bark wallet, wait for activation, make a protected call, confirm balance deduction. Everything came back clean. Both Ark and Lightning payments were extremely fast and felt basically instant! :high_voltage:

Things from the changelog I’ll probably care about next:

  • Lightning fee controls / routing fee limits — matters once real sats are flowing
  • Sync interval tuning — tradeoff between responsiveness and overhead for session activation
  • Fee estimation endpoints — relevant if I build admin sweep/withdraw tooling

Tor support also caught my eye, although I haven’t tested that path yet.

Lot of other good stuff in there too but those are the most practical for what I’m doing right now.

Thanks to the team for continuing to push forward! :slight_smile:

3 Likes
8

I just tested with my Bark 0.1.1 wallet and an API client, and it’s working smoothly. Great work, @PiHiker!

1 Like
9

Just made a ArkAPI demo video.
Check it out @PiHiker
Link: https://x.com/2ndpsy/status/2042312866653507665

2 Likes
10

Just saw it! Thanks @psycarlo for putting together the demo video and sharing ArkAPI on X. Really appreciate it!

1 Like
11

Telegram bot is live

Quick update — ArkAPI now has a Telegram client: @ArkAPI_bot

Each Telegram user gets their own private session. Hit /fund, get some starter signet sats, and start querying. No dashboard, no signup, no API keys.

Both payment rails, Ark and Lightning, are fully implemented and tested end to end on signet. /fund presents an Ark address and a Lightning invoice side by side. Either one works. Payment confirms, session activates, bearer token is issued, and every subsequent API call deducts sats from that session. Receipts show which rail funded the session. The full cycle from funding to authenticated API call is working on both rails today.

Starter sats come from arkfaucet.com, a separate service built to remove the entry barrier completely. New users get a small amount of signet sats to start testing immediately without needing to source them elsewhere. Per-IP daily limits and global anti-abuse controls are in place to keep it sustainable.

Sessions stay alive for 24 hours of inactivity, and you can top up with /fund anytime without losing your current balance.

The bot currently exposes the full ArkAPI catalog:

Session: /fund (shows Ark address + Lightning invoice + QR), /balance, /activity (receipts and paid calls)

Bitcoin: /price (BTC price + sentiment), /whale (whale signal), /news (headlines)

AI: /chat, /image, /summarize

OSINT: /domain (aggregated intel with optional AI summary), /dns, /whois, /ssl, /headers, /ip (combined geolocation/ASN/abuse/URLhaus)

Utility + Web: /weather, /translate, /paste (with TTL, view limits, burn-after-read), /markdown (URL to markdown), /qr (generate a QR code from any text or URL), /screenshot (full-page capture of any URL), /markets (prediction markets)

Every response shows cost and remaining balance, so the pay-per-call model is visible with each query.

The motivation was partly selfish. I run domain and infosec lookups constantly and wanted them on my phone . But it also turned out to be the lowest friction way to let someone try ArkAPI.

Try it: t.me/ArkAPI_bot Landing page: arkapi.dev/telegram-bot

Feedback welcome, especially on which endpoints are useful and what’s missing.

2 Likes
12

Bark 0.1.3 upgrade

Upgraded both arkapi.dev and arkfaucet.com to Bark 0.1.3 and have been running it through its paces on Signet.

Two changes made it into production testing. First, ArkAPI now uses Bark’s private server access token flow. ArkAPI now supports connecting to Ark servers that require bearer token authentication.

Second, Bark 0.1.3 added the ability to cancel in-flight Lightning receives before they settle. That’s now wired into ArkAPI so stale or abandoned receive attempts get cleaned up deliberately rather than left to time out.

On the faucet side, we caught and fixed a proxy-aware IP detection bug that was grouping different users under the same upstream IP and triggering the 24-hour claim limit incorrectly. Faucet claims are working properly again.

Full Signet test pass across API endpoints, wallet balance checks, funding events, receive creation, status reads, and cancel behavior all looked good.

3 Likes
13

Just tried the new faucet. Really appreciate the simplicity of it. The Github login for the Second faucet is just enough friction to make it a little annoying :-). Great work!

Going to give the Telegram bot a try next and will report back!

2 Likes
14

Today we rolled out a focused reliability update to https://arkapi.dev and the supporting signet
services.

The main goal was to make the payment flow more resilient and reduce stuck state. We
improved Telegram session cleanup, made session creation recover more gracefully when a
payment rail is temporarily unavailable, reduced background polling noise, and hardened
https://arkfaucet.com startup and wallet-lock handling.

We also tightened Lightning receive handling so incomplete or canceled receives are not
mistaken for successful payments.

Net result: fewer dead ends for Telegram users, cleaner recovery under load, and a more
dependable end-to-end funding flow.

15

ark.signet.2nd.dev seems to be rate-limiting our bark wallets right now, so arkapi.dev Lightning
funding and arkfaucet.com sends are flaky. arkapi.dev itself, existing funded tokens, and the
Ark address path on /fund/ all still work.

16

The overly-aggressive rate limit is a known bug and we’re working on getting a fix out asap. Watch out for 0.1.4.

Anyway, great to hear ArkAPI’s getting more robust. We’ll run off some of our own video demos and push them out on socials soon!

1 Like
17

Thanks for the heads-up. That matches what we were seeing on our side as well. We’ve
disabled Lightning for now while we keep the Ark-only paths stable, and we’ve also moved
Bark into a safer report-only posture so it doesn’t take payment rails offline during the
known 0.1.3 rate-limit issue.

Appreciate the work on 0.1.4 and happy to retest once it’s out.

1 Like
18

@PiHiker 0.1.4 is out but you should have already seen the issue fixed as of yesterday. Let us know how it goes.

1 Like
19

Thanks @nwoodfine. I upgraded to 0.1.4 and the payment/session flow is looking much healthier now.

I also found and fixed a faucet-side wallet state issue where a stuck refresh/over-depth VTXO could block payouts. After cleanup and some hardening, Ark-funded sessions, faucet grants, and basic API billing tests are working again on signet. I will keep monitoring and report back if anything else shakes loose. Lightning is still disabled for now, I test it again later this week and re-enable it if things stay healthy.

20

Great work on going mainnet! Congrats to the whole team!!!

I upgraded Bark to the latest version, 0.2.3, today and tested the APIs afterward. Everything is working well and the logs are looking healthy.

Planning to move toward mainnet in the next few days. :slight_smile: