#### You build / provide
- Org registration details ([what exactly](/getting-started/onboarding))
- **Push**: an API client that signs requests
- **Pull**: one cursor-paged read endpoint
- A webhook receiver (HTTPS, verifies signatures, dedupes) — or use the
[poll API](/receiving-updates/poll-api) instead
- **Mode A**: your QR image / UPI ID / bank details
- **Mode B**: a mint-link endpoint + capture confirmations
#### We provide
- Sandbox + production credentials and this documentation
- The entire field operation: partner network, visits, RBI-compliant conduct
- Case management, deduplication, geocoding, assignment
- Signed webhooks with retries, a poll API, delivery log + self-serve replay
- Proof verification (Mode A) and payment ledger either way
- The [reference implementation](/testing/reference-implementation) of every
contract you need to build
Whatever you choose, the [data contract](/core-concepts/data-contract) and the
[event stream](/receiving-updates/event-reference) are identical — switching
paths later doesn't change your parser.
---
# Onboarding & registration
_Everything you provide to register, and everything you receive back._
Source: https://developers.fluxusforge.in/getting-started/onboarding
# Onboarding & registration
Registration is a short exchange with the Fieldproof integration team. Here is
the complete list — gather these before your kickoff call and onboarding
typically completes the same day.
## What you provide
### 1. Organisation identity
| Item | Notes |
|---|---|
| **Organisation code** | Short uppercase identifier (e.g. `LENDER_X`). Immutable — it tags every case, payment, and event of yours. |
| Display name & short name | Shown to borrowers in the partner app and on receipts. |
| Logo (PNG/SVG) + brand colour | Borrower-facing screens re-skin per lender. |
| Registered address & support phone | Printed on receipts. |
### 2. Compliance
| Item | Notes |
|---|---|
| **RBI regulatory disclosure text** | The fair-practices line printed on every borrower receipt, e.g. *"Payment collected by Quikkred Financial Services on behalf of <you> for loan {{loan}}."* Have your legal team approve the wording. |
| Receipt footer note (optional) | Refund/dispute contact wording. |
> **ENTITY NAME IS LEGALLY BOUND TO YOUR APPROVAL** — The disclosure names the **collecting legal entity**, not the product brand.
> Fieldproof is the product; the collecting entity on your receipts is whatever
> your legal team approved at onboarding. If that entity ever changes, every
> live lender must re-approve the wording before the change ships — it cannot be
> updated unilaterally.
### 3. Technical
| Item | Notes |
|---|---|
| Integration mode | Push / pull / CSV — see [integration paths](/getting-started/integration-paths). |
| **Webhook endpoint** | One HTTPS URL. Plus which [event types](/receiving-updates/event-reference) you want (default: money + terminal events). |
| Payment mode + artefacts | **Mode A**: static QR image, UPI ID, bank details. **Mode B**: your mint-link API spec + auth header. |
| *(Pull mode)* your read API | URL, auth header we should send, desired schedule. |
| *(Optional)* IP allowlist | Restrict your API keys to your egress IPs. |
| Technical contact | Email + phone — receives delivery-failure alerts and coordinates key rotation. |
## What you receive
| Item | Notes |
|---|---|
| **Sandbox credentials** | `apiKeyId` (e.g. `pk_yourorg_test_…`) + HMAC secret — delivered over a secure channel, shown once. Work only against the sandbox host. |
| **Production credentials** | Issued after the [go-live checklist](/testing/go-live-checklist) passes. Live keys work only against production. |
| Base URLs | Sandbox: `https://alpha-gig.quikkred.in` (test keys) · Production: `https://gig.quikkred.in` (live keys, after go-live). |
| This documentation + [OpenAPI spec](/api-reference) | The spec is also served by the API itself at `GET /api/v1/partner/openapi.json`. |
| The [reference implementation](/testing/reference-implementation) | Runnable example of every contract. |
> **CREDENTIALS ARE SHOWN ONCE** — The HMAC secret cannot be re-displayed — store it in your secrets manager on
> receipt. If lost, request a rotation: a new secret is issued while the old one
> keeps working until you confirm cutover ([key security](/authentication/key-security)).
## The onboarding sequence
```mermaid
flowchart TD
A[You send registration details] --> B[We register your org + config]
B --> C[Sandbox credentials issued]
C --> D[You integrate & test against sandbox]
D --> E[Go-live checklist together]
E --> F[Production credentials issued]
F --> G[First production push]
```
---
# Environments & credentials
_Sandbox vs production, key environments, and how credentials behave._
Source: https://developers.fluxusforge.in/getting-started/environments
# Environments & credentials
| | **Sandbox** | **Production** |
|---|---|---|
| Purpose | Build + test your integration end-to-end | Live borrower data |
| Accepts | **Test keys only** (`pk_…_test_…`) | **Live keys only** (`pk_…_live_…`) |
| Data | Test cases, simulated partners | Real cases, real field partners |
| Signature debugger | [`/debug/echo-signature`](/authentication/debugging-signatures) available | Not available (by design) |
| Base URL | `https://alpha-gig.quikkred.in` | `https://gig.quikkred.in` |
The environment split is **enforced by the servers, not by convention** — a
test key presented to production is rejected with `401`, and vice versa. There
is no way to accidentally point a test integration at live data.
## Credential model
Your credential has two parts:
- **`apiKeyId`** — public identifier, sent as the Bearer token. Identifies
your organisation; safe to log.
- **`hmacSecret`** — never transmitted. Proves possession by
[signing every request](/authentication/signing-requests) and verifies the
webhooks we send you. Store only in your secrets manager.
Both sandbox and production get their own independent pair.
## Operational properties
| Property | Behaviour |
|---|---|
| Rotation | Zero-downtime: a new secret is issued while the old stays valid until you confirm cutover. |
| Revocation | Effective within 60 seconds. |
| Brute-force lockout | Repeated invalid signatures soft-lock the key for 15 minutes (`429 AUTH_LOCKED`) and alert both sides. |
| Rate limits | Default 60 requests/min and 10 case-batches/hour per organisation — see [errors & rate limits](/resources/errors). |
| IP allowlist | Optional — your keys can be restricted to your egress IPs. |
---
# Quickstart: first case in 15 minutes
_Health check → push a case → receive your first webhook._
Source: https://developers.fluxusforge.in/getting-started/quickstart
# Quickstart
You need your **sandbox credentials** ([onboarding](/getting-started/onboarding));
the sandbox base URL is `https://alpha-gig.quikkred.in`. Three steps: verify auth → push one case → receive the
webhook.
## 1. Verify your credentials
Every request is HMAC-signed ([full spec](/authentication/signing-requests)).
Minimal signed `GET`:
```js title="health-check.js (Node 18+)"
const crypto = require("crypto");
const BASE = "https://alpha-gig.quikkred.in"; // sandbox (test keys); production: https://gig.quikkred.in
const KEY = process.env.QK_KEY_ID; // pk_yourorg_test_...
const SECRET = process.env.QK_SECRET;
async function call(method, path, bodyObj) {
const body = bodyObj ? JSON.stringify(bodyObj) : "";
const ts = Date.now().toString();
const canonical = `${method}\n${path.split("?")[0]}\n${ts}\n${body}`;
const sig = crypto.createHmac("sha256", SECRET).update(canonical).digest("hex");
const res = await fetch(BASE + path, {
method,
headers: {
authorization: `Bearer ${KEY}`,
"content-type": "application/json",
"x-quikkred-timestamp": ts,
"x-quikkred-signature": sig,
},
...(bodyObj ? { body } : {}),
});
return { status: res.status, json: await res.json() };
}
call("GET", "/api/v1/partner/health").then(console.log);
// → { status: 200, json: { ok: true, lenderCode: "YOURORG", env: "test", ... } }
```
A `401 SIGNATURE_INVALID`? Use the
[signature debugger](/authentication/debugging-signatures) — it shows the exact
canonical string the server computed so you can diff yours.
## 2. Push a case (dry-run first)
```js
const batch = {
rows: [{
sourceLoanNumber: "LN-2026-0001", // your stable loan ID
borrower: {
name: "Test Borrower",
phone: "9876543210", // Indian mobile
address: { line1: "12 MG Road", city: "Bengaluru", pincode: "560001" },
},
loan: { outstandingAmount: 12500, dpd: 45, emiAmount: 2500 },
}],
};
// Validate without writing:
await call("POST", "/api/v1/partner/cases?dryRun=1", batch);
// → summary: { created: 1, errored: 0 }, errors: []
// Commit:
await call("POST", "/api/v1/partner/cases", batch);
```
Re-sending the identical batch is always a safe no-op, and re-sending a row for
an existing loan **updates** it — duplicates are impossible by design
([reliability](/core-concepts/reliability)).
## 3. Receive your first webhook
Within seconds of the commit, your registered endpoint receives a signed
`case.received` event:
```json
{
"eventId": "evt_9f2c81a4d0b1e6a2c3d4",
"type": "case.received",
"occurredAt": "2026-07-23T09:31:00.000Z",
"version": 1,
"lenderCode": "YOURORG",
"sourceLoanNumber": "LN-2026-0001",
"sequence": 1,
"payload": { "sourceLoanNumber": "LN-2026-0001", "caseId": "CC-2026-XXXXXXX", "status": "pending" }
}
```
Your receiver must verify the signature, respond `2xx` fast, and dedupe on
`eventId` — the [webhooks page](/receiving-updates/webhooks) has the complete
receiver contract and copy-paste receivers in Node and Python.
No endpoint yet? The same events are available by polling:
```js
await call("GET", "/api/v1/partner/cases/updates?limit=50");
```
## Where to go next
- [Updating your LMS from our events](/receiving-updates/updating-your-lms) — turn webhooks into loan records
- [Data contract](/core-concepts/data-contract) — every field you can send
- [Webhooks](/receiving-updates/webhooks) — build a correct receiver
- [Payments](/payments/how-money-flows) — pick how money reaches you
- [Go-live checklist](/testing/go-live-checklist) — what we verify together
---
# Case lifecycle & statuses
_The external status model and visit outcomes you will see._
Source: https://developers.fluxusforge.in/core-concepts/case-lifecycle
# Case lifecycle & statuses
Your system sees a deliberately **simple four-state model** — internal
operational sub-states are mapped so we can evolve them without breaking you.
```mermaid
flowchart TD
S([your push]) -->|case.received| P[pending]
P -->|case.assigned| IP[in_progress]
IP -->|"payment.collected (full)