SnapAct Trust API — verified-partner data for commerce platforms

The response

One call. HMAC-signed. Use it before you ship, lend, list, or onboard.

Every response carries an HMAC-SHA256 signature over its canonical fields so your audit logs can re-verify the decision months later. Scores are computed nightly across all partners and updated within seconds of a dispute resolving or an admin status change.

# GET https://api.trust.snapact.io/v1/partner/{id}
# Authorization: Bearer snapact_trust_...

{
  "ok": true,
  "api_version": "v1",
  "partner_id": "snapact_partner_...",
  "status_visible_to_buyers": true,
  "trust_score": 89,
  "components": {
    "completion": 0.975,   // escrow completion, last 90d
    "dispute":    0.875,   // inverted dispute rate
    "rating":     0.875,   // buyer ratings, sample-weighted
    "tenure":     0.88,    // account age, log-saturating at 12 months
    "kyc":        0.7,     // identity verification tier
    "moderation": 1.0      // recent admin / system flags
  },
  "score_updated_at": "2026-09-13T03:00:00Z",
  "stale": false,
  "signed_at": "2026-09-13T14:22:11Z",
  "signature": "a8f9e7c2..."
}

Two endpoints

Look up by ID, or reverse-lookup by phone.

Most integrators already have the partner's SnapAct ID — passed inline in an order, a Connect API row, or supplied by the partner during onboarding. Use the partner endpoint. When you're meeting a partner for the first time and only have a phone number, use the lookup endpoint. Both return the same signed payload shape.

By partner ID

When your system already has the partner's SnapAct ID (from an order webhook, Connect API row, or partner-supplied during onboarding).

              GET /v1/partner/{id}
            

Scope: trust_v1_partner. Default 60 req/min.

By phone (reverse lookup)

When you're vetting a partner you've never transacted with — bank loan applications, KYB onboarding, logistics dispatch from a phone-only handoff.

              GET /v1/lookup?phone=…
            

Scope: trust_v1_lookup (separate). Default 30 req/min. Returns at most one match. Raw phone never persisted in logs — only a salted hash.

Why it exists

Verifying sellers in Africa is hard. SnapAct has the operational data.

Banks underwriting SME partners can't see real revenue. Marketplaces onboarding new sellers can't confirm they're not a scam. Logistics platforms accepting pickup jobs can't tell a seven-month-old verified business from a three-week-old fake. SnapAct runs the escrow rail those partners settle through — every completed order, every dispute, every refund, every rating becomes input to the score.

Ground-truth verification

Every score reflects real escrow outcomes, not self-reported reputation. KYC tier, completion rate, dispute history, and tenure are weighted into the final number.

Continuous refresh

Scores recompute nightly across every approved partner. Material status changes — dispute resolutions, KYC upgrades, archive, key rotation — trigger an immediate refresh within seconds.

Provenance-signed

HMAC-SHA256 signature over the canonical response fields. Auditable years after the decision was made. Defends against tampering in caches, proxies, and downstream systems.

36h

Maximum score staleness before the response flags stale: true.

<200ms

Target p95 response time including authentication and signature.

SHA-256

HMAC algorithm over canonical pipe-separated fields. Versioned.

6

Trust components surfaced separately so you can apply your own thresholds.

Who uses it

Built for the platforms operating in the same market.

Marketplaces

Verify a seller before approving their listing. Surface a verified badge to your buyers when the score crosses your threshold.

Challenger banks

Underwrite SME credit using real escrow throughput as the operational baseline, not self-reported revenue.

Logistics

Accept or decline pickup jobs based on dispute history and verified-address signal before dispatching a rider.

B2B distributors

Vet downstream partners before extending inventory credit or wholesale pricing. Re-verify on every restock.

Insurance & risk

Price coverage or claim outcomes against the partner's verified operating history. Re-pull on every renewal.

Compliance teams

Re-run signed verifications years later to defend a decision in an audit. The signature is the receipt.

Integration

Server-to-server. Two lines of code, one HTTP header.

Trust API credentials are server-side secrets, issued directly by SnapAct after a brief access review. Store the key in your secret manager under any name you choose — the samples below use SNAPACT_TRUST_KEY as the placeholder. Never call the API from a browser, mobile client, or any environment a third party can observe.

                Look up by partner ID
                GET /v1/partner/{id}
              
curl -i \
  -H "Authorization: Bearer $SNAPACT_TRUST_KEY" \
  https://api.trust.snapact.io/v1/partner/snapact_partner_d11b0dbc-7a84-4dbd-b7e7-ae9a2ff1fc04

                Reverse-lookup by phone
                GET /v1/lookup?phone=…
              
# Requires the trust_v1_lookup scope on the key
curl -i \
  -H "Authorization: Bearer $SNAPACT_TRUST_KEY" \
  "https://api.trust.snapact.io/v1/lookup?phone=2348012345678"

                Look up by partner ID
                GET /v1/partner/{id}
              
const resp = await fetch(
  `https://api.trust.snapact.io/v1/partner/${partnerId}`,
  { headers: { Authorization: `Bearer ${process.env.SNAPACT_TRUST_KEY}` } }
);

if (resp.status === 401) throw new Error('Invalid SnapAct Trust key');
if (resp.status === 429) {
  const retry = Number(resp.headers.get('Retry-After') || 60);
  // back off and retry after `retry` seconds
}

const data = await resp.json();
if (!data.ok) throw new Error(data.error);

// Decision example:
if (data.trust_score < 60) {
  return { allow: false, reason: 'low_trust' };
}

                Reverse-lookup by phone
                GET /v1/lookup?phone=…
              
const phone = '2348012345678';
const lookup = await fetch(
  `https://api.trust.snapact.io/v1/lookup?phone=${encodeURIComponent(phone)}`,
  { headers: { Authorization: `Bearer ${process.env.SNAPACT_TRUST_KEY}` } }
);

const data = await lookup.json();
if (!data.matched) {
  // No SnapAct partner has this phone
  return { allow: false, reason: 'not_a_snapact_partner' };
}

// Same response shape as /v1/partner/{id}
const partnerId = data.partner_id;
const score = data.trust_score;

                Look up by partner ID
                GET /v1/partner/{id}
              
import os, requests

resp = requests.get(
    f"https://api.trust.snapact.io/v1/partner/{partner_id}",
    headers={"Authorization": f"Bearer {os.environ['SNAPACT_TRUST_KEY']}"},
    timeout=5,
)
resp.raise_for_status()

data = resp.json()
score = data["trust_score"]
visible = data["status_visible_to_buyers"]

                Reverse-lookup by phone
                GET /v1/lookup?phone=…
              
import os, requests

lookup = requests.get(
    "https://api.trust.snapact.io/v1/lookup",
    params={"phone": "2348012345678"},
    headers={"Authorization": f"Bearer {os.environ['SNAPACT_TRUST_KEY']}"},
    timeout=5,
)
lookup.raise_for_status()

match = lookup.json()
if match["matched"]:
    partner_id = match["partner_id"]
    score = match["trust_score"]

Errors surface as JSON: 400 INVALID_PHONE / INVALID_PARTNER_ID, 401 INVALID_KEY, 403 INSUFFICIENT_SCOPE (when the key doesn't have trust_v1_lookup or trust_v1_partner), 404 PARTNER_NOT_FOUND (partner endpoint only — the lookup endpoint returns 200 with matched: false for no-match), 429 RATE_LIMITED with Retry-After header. The X-RateLimit-Limit response header shows your per-minute cap.

How it works

From your request to a signed response.

Your backend calls the API

Server-side GET to /v1/partner/{id} with the Bearer credential. TLS-terminated at the edge.

SnapAct authenticates the key

Constant-time hash verification against the issued key. Scope check against the requested resource. Per-key rate limit applied.

Current score is fetched

The partner's latest trust score, components, and freshness timestamp are read from the SnapAct ledger. No model inference — deterministic weighted sum.

Response is HMAC-signed

Canonical fields are signed with SHA-256. Your backend stores the response + signature in your audit log to defend the decision later.

Security

Production guarantees, not marketing claims.

The API is the contract — every guarantee below is enforced in code, audited on every request, and described publicly so your security team can review it before integration.

Server-to-server only

No public sign-up. No browser SDK. Credentials are issued one-by-one to named integrators and live only in your server-side secret manager.

Constant-time auth

Hash comparison runs in constant time. Lookup-key absence is padded so timing analysis can't distinguish "no row" from "wrong secret."

Scope-limited keys

Each key carries an explicit scope array. trust_v1_partner grants ID lookup only. trust_v1_lookup grants the reverse-phone-lookup separately — typically issued only to banks doing KYB.

Per-key rate limit

Configurable per integrator. Returns 429 with Retry-After when exceeded. A coarse per-IP floor stops brute force at the network edge.

Instant revocation

Compromised credentials die on the next request after revocation. No grace window. Audit log captures the reason and who revoked.

Surface isolation

The Trust API hostname serves nothing else. A leaked key cannot escalate into other SnapAct surfaces — the rest of the worker is hard-404'd on this host.

Verifying a response signature

// Reconstruct the canonical string the API signed:
const canonical = [
  "v1",
  data.partner_id,
  data.trust_score ?? "",
  data.score_updated_at ?? "",
  data.signed_at,
].join("|");

// Compute HMAC-SHA256 with your shared signing key:
const expected = crypto
  .createHmac("sha256", sharedSigningKey)
  .update(canonical)
  .digest("hex");

if (expected !== data.signature) {
  throw new Error("Trust response signature mismatch");
}

Access

Apply for API credentials.

Credentials are issued directly. Tell us your platform, the integration you intend to build, and the decision the trust signal will inform. We respond within two business days.

Contact the SnapAct Trust team.

Include your platform, expected monthly call volume, and a short description of the decision the signal will influence (onboarding, underwriting, dispatch, etc.). We'll reply with a key and integration guidance.

Email trust@snapact.io Learn about SnapAct

Verified-partner data, as one signed API call.

One call. HMAC-signed. Use it before you ship, lend, list, or onboard.

Look up by ID, or reverse-lookup by phone.

By partner ID

By phone (reverse lookup)

Verifying sellers in Africa is hard. SnapAct has the operational data.

Ground-truth verification

Continuous refresh

Provenance-signed

Built for the platforms operating in the same market.

Server-to-server. Two lines of code, one HTTP header.

Look up by partner ID

Reverse-lookup by phone

Look up by partner ID

Reverse-lookup by phone

Look up by partner ID

Reverse-lookup by phone

From your request to a signed response.

Your backend calls the API

SnapAct authenticates the key

Current score is fetched

Response is HMAC-signed

Production guarantees, not marketing claims.

Server-to-server only

Constant-time auth

Scope-limited keys

Per-key rate limit

Instant revocation

Surface isolation

Verifying a response signature

Apply for API credentials.

Contact the SnapAct Trust team.