Developer Docs v1.0REST API • Async Queue • Defect Extraction

Krend Developer Documentation

Everything you need to ingest customer feedback, stream review telemetry, automate root-cause defect extraction, and prioritize engineering fixes.

Quickstart (3 mins)Authentication Ingestion API Defect Extraction Dashboard & Triage Rate Limits & Security Roadmap

3-Minute Quickstart

Connect your application and start streaming reviews into Krend. All ingestion is asynchronous: reviews are persisted immediately, queued for analysis, and parsed by background workers to extract defects, sentiments, and insights.

Step 1: Obtain your API KeyDashboard > API Keys

Navigate to the API Keys tab in your console and generate a new key prefixed with krend_live_. Store this key securely; only its SHA-256 hash is persisted.

Step 2: Send your review payloadUnified Ingest

Submit one or more reviews via POST /v1/reviews. The payload wraps review items in a reviews array (supporting 1 to 500 reviews per request):

Quickstart Ingestion (POST /v1/reviews)

import requests

url = "https://krend.pages.dev/v1/reviews"
headers = {
    "Authorization": "Bearer krend_live_YOUR_KEY",
    "Content-Type": "application/json",
}

payload = {
    "reviews": [
        {
            "content": "Checkout crashed repeatedly on mobile Safari during Apple Pay validation",
            "rating": 1,
            "customer_id": "cust_48921",
            "metadata": {
                "platform": "ios",
                "version": "4.2.1"
            }
        }
    ]
}

response = requests.post(url, json=payload, headers=headers)
print(response.status_code, response.json())
# Expected: 202 {"batch_id": "...", "accepted": True, "reviews_queued": 1}

Step 3: Monitor asynchronous analysisWorker Pipeline

Your reviews are immediately written with status pending. The background worker pulls queued items, runs defect and sentiment analysis, updates review status to analyzed, and posts results to your Analytics and Bug Tracker views.

Authentication & Key Management

All requests to the Krend REST API must include a valid Bearer token in the Authorization HTTP header. Keys are created and managed via the dashboard.

Header Format:

Authorization: Bearer krend_live_948fbc29481ae9876e93...

Cryptographic Storage

Plaintext API keys are generated once and never stored in the database. Only the SHA-256 hash is persisted. The first 15 characters (e.g. krend_live_ab12) are stored as a prefix identifier for listing and management.

Per-Key Rate Limits

Each API key has an independent rate limit (default: 60 requests/minute, configurable up to 10,000 requests/minute in the database). Exceeding the key's limit returns HTTP 429 with standard Retry-After headers.

Security Guideline: Live API keys should only be used in trusted server environments. Never embed krend_live_ keys in frontend bundles or mobile client code.

Ingestion API: POST /v1/reviews

HTTP 202 ACCEPTED

The unified review ingestion endpoint accepts single reviews as well as bulk batches. Any submission containing between 1 and 500 reviews in the reviews array is validated, saved with status pending, and scheduled for asynchronous background analysis.

Request Payload Schema

reviews*array

Array of review items to ingest. Minimum: 1 item. Maximum: 500 items per request.

reviews[].content*string

The raw text content of the review, customer complaint, or feedback message (1 to 10,000 characters). Required for every item.

reviews[].ratinginteger

Numeric satisfaction score from 1 to 5. Optional.

reviews[].customer_idstring

Customer identifier in your system (1 to 128 characters). Optional.

reviews[].metadataobject

Arbitrary JSON object for contextual metadata (e.g. platform, app version, channel, region). Stored as JSONB in Postgres.

Submitting Multiple Reviews (Batch)

import requests

url = "https://krend.pages.dev/v1/reviews"
headers = {
    "Authorization": "Bearer krend_live_YOUR_KEY",
    "Content-Type": "application/json",
}

# Ingesting a batch of customer reviews (up to 500 items)
payload = {
    "reviews": [
        {
            "content": "Checkout crashed repeatedly on mobile Safari during Apple Pay validation",
            "rating": 1,
            "customer_id": "cust_101",
            "metadata": {"platform": "ios", "version": "4.2.1"}
        },
        {
            "content": "Fast delivery and great customer support team!",
            "rating": 5,
            "customer_id": "cust_102",
            "metadata": {"channel": "in_app"}
        },
        {
            "content": "Cannot export monthly billing invoice as PDF on Firefox",
            "rating": 2,
            "customer_id": "cust_103",
            "metadata": {"browser": "firefox"}
        }
    ]
}

response = requests.post(url, json=payload, headers=headers)
print(response.status_code, response.json())

Success Response (HTTP 202 Accepted)Immediate Acknowledgment

{
  "batch_id": "b3e9a12c-409b-4b11-8f52-871d3a4b9123",
  "accepted": true,
  "reviews_queued": 2
}

The batch_id is a unique UUID assigned to this queue job. The number of accepted reviews is returned in reviews_queued. Because analysis is asynchronous, reviews are immediately available in the database with status pending.

Defect Extraction & Insight Intelligence

When the asynchronous background worker processes a batch of pending reviews, it extracts structural software bugs and groups qualitative feedback into actionable categories.

Loss-Causing Bugs

Identifies technical defects from low-rating feedback. Each record contains:

title: Root defect description
impactSummary: UX & technical impact
frequency: Mention count across batch
status: open, investigating, or resolved

Qualitative Insights

Synthesizes feedback patterns categorized into:

liked_feature: Praised features
repeated_complaint: Recurring UX friction
to_fix: Actionable checklist items with urgency indicators

Review Tagging

Every review in the batch receives relational tags:

sentiment: positive, neutral, or negative
primaryCategory: Functional area (e.g. checkout, auth, UI)

Review Status Lifecycle

1. status: "pending"

→

2. Background Worker Processing

→

3. status: "analyzed"

If an unrecoverable processing error occurs after 3 worker retries, the review is marked with status: "failed" and the specific failure reason is recorded in failureReason.

Dashboard & Triage Architecture

The Krend product provides a structured web console for managing your feedback corpus and monitoring defect resolution:

/analyticsOverview & Metrics

Visualizes total reviews, pending review counts, bug counts categorized by status (Open, Investigating, Resolved), high-priority defect lists, and synthesized user praise vs complaint trends.

/bugsDefect Tracker

Interactive triage interface. Engineering teams can filter defects by frequency, review impact summaries, and update bug statuses via PATCH /v1/bugs/:id.

/api-keysAPI Key Console

Create new ingest keys prefixed with krend_live_, configure individual rate limits, inspect creation dates, and revoke compromised credentials.

/settingsOrganization Settings

Manage tenant business identity, view account details, and configure platform preferences.

Programmatic Bug Status Update: PATCH /v1/bugs/:id

curl -X PATCH https://krend.pages.dev/v1/bugs/a1b2c3d4-e5f6-7890-abcd-ef1234567890 \
  -H "Authorization: Bearer YOUR_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"status": "investigating"}'

Rate Limits & Defensive Security

Krend protects backend database stability and tenant resources through multiple layers of rate control and input defense:

Configurable Rate Limiting

Every API key carries its own rate limit stored in the database (default: 60 requests/minute). When exceeded, the API responds with HTTP 429 and includes a Retry-After header with the exact cooldown seconds remaining.

Input Sanitization & Defense

Review text is bounded to 10,000 characters and sanitized before background analysis to strip prompt injection delimiters. Schema validation errors return clean HTTP 400 Bad Request envelopes without exposing internal database structures.

Standard HTTP Error Responses

400 Bad RequestPayload failed validation (e.g. reviews array empty or exceeding 500 items).

401 UnauthorizedMissing or invalid Bearer API key in Authorization header.

429 Too Many RequestsAPI key rate limit exceeded. Check Retry-After header.

500 Internal Server ErrorUnexpected server failure. Internal diagnostics are logged server-side.

Future Roadmap

The following features are actively under development and scheduled for upcoming releases:

Outbound Webhook DeliveryPlanned

Subscribe your internal endpoints to receive automated notifications when new critical defects are extracted or when negative feedback spikes occur.

Issue Tracker Two-Way SyncPlanned

Direct synchronization between Krend defect items and your engineering issue trackers (GitHub Issues, Linear, Jira).