PayCraft · API v1

Automate billing setup
without a browser session.

Check whether every payment provider can actually transact — live and in test — and reconcile your catalogue with Stripe, Razorpay, Google Play and the App Store. Built for CI, deploy pipelines and agents.

Quick start

Create a key under Settings → Developer API. It is shown once — PayCraft stores a hash, not the key.

export PAYCRAFT_KEY="pcsk_..."

# Can every provider transact yet?
curl -s -H "Authorization: Bearer $PAYCRAFT_KEY" \
  https://api.paycraft.mobilebytesensei.com/v1/readiness | jq '.summary'

# { "total": 4, "needs_manual_action": 2, "live_ready": 4, "test_ready": 2 }

# What would a sync change? Then do it, echoing the count back.
N=$(curl -s -H "Authorization: Bearer $PAYCRAFT_KEY" \
  https://api.paycraft.mobilebytesensei.com/v1/sync | jq .confirm_count)

curl -s -X POST -H "Authorization: Bearer $PAYCRAFT_KEY" \
  -H "content-type: application/json" -d "{\"confirm_count\": $N}" \
  https://api.paycraft.mobilebytesensei.com/v1/sync

Endpoints

Every endpoint requires exactly one scope. The tenant is derived from the key — no endpoint accepts a tenant id.

PathScopeReturns
GET /v1/tenant tenant:read Plan, limits and the calling key's scopes
GET /v1/readiness readiness:read Per-provider, per-mode readiness + manual steps
GET /v1/products products:read Catalogue with each provider's synced ids
GET /v1/products/{id} products:read One product, with pricing rows
POST /v1/products/{id}/sync products:sync Push one product to its providers
GET /v1/providers providers:read Connected providers and payment links
GET /v1/sync products:read Drift report — what a sync would do
POST /v1/sync products:sync Run the drain (confirm_count required)
GET /v1/sync/events products:read Per-provider events for a run
GET /v1/subscribers subscribers:read Subscription records
GET /v1/entitlements subscribers:read Canonical entitlement state
GET /v1/coupons coupons:read Discount codes and provider counterparts
GET /v1/paywall paywall:read Paywall configuration the SDK renders
GET /v1/webhooks webhooks:read Inbound webhook deliveries
GET /v1/audit audit:read Who changed what, including this API

How it behaves

The key names the tenant

No endpoint takes a tenant id — in a body, a query or a header. A bearer credential that could name the tenant would be a key to every tenant.

Scoped, not all-or-nothing

A read key cannot bulk-write to live payment providers, even though both sit behind the same authentication.

Writes ask twice

POST /v1/sync requires the count from GET /v1/sync. A mismatch returns 409 — the set changed between looking and acting.

200 is not "all fine"

A sync reports per-provider verdicts. Read failed and skipped; a provider can fail while the call succeeds.

Hashed at rest

Only a SHA-256 of each key is stored. A database dump yields nothing usable, and a lost key is replaced, never recovered.

Rate limited per tenant

120 requests, refilling at 1/second. Over the limit returns 429 — sized for a runaway script, not a human.

What the API cannot do

Worth knowing before you automate against it.

Google Play and App Store test mode cannot be enabled through any API. Neither store exposes a way to turn it on or to assert that it is on. Those rows carry manual_steps — ordered instructions for a person with a device — and turn green only when a real sandbox purchase reaches PayCraft. Every other provider reaches test readiness through a test credential plus a sync.