Developer Docs v1.1krend-js SDK • REST API • Defect Extraction

Krend Developer Documentation

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

Documentation Mode:
krend-jsv1.1.0 • npm

Type-safe client with automatic exponential retries and batch buffering.

1

3-Minute Quickstart

krend-js SDK Setup

Get up and running with the official krend-js package in under 3 minutes. The SDK provides strong TypeScript typings, automatic exponential retries with jitter, and intelligent batch queuing.

Step 1: Install krend-jsTerminal

Add the official package to your project using your preferred package manager:

npm install krend-js
Step 2: Initialize & Ingest ReviewsTypeScript / Node

Initialize the client with your API key from API Keys and submit feedback in 3 lines:

// 1. Install: npm install krend-js
import { Krend } from "krend-js";

// Initialize with your live server API key
const krend = new Krend({ apiKey: process.env.KREND_API_KEY! });

// Ingest customer reviews in 3 lines of code
const result = await krend.reviews.submit({
  content: "Checkout crashed repeatedly on mobile Safari during Apple Pay validation",
  rating: 1,
  customer_id: "cust_48921",
  metadata: {
    platform: "ios",
    app_version: "4.2.1"
  }
});

console.log("Accepted:", result.accepted); // true
console.log("Batch ID:", result.batchId);   // "b3e9a12c-409b-4b11-8f52-871d3a4b9123"
Step 3: Automated Telemetry & TriageDashboard Sync

Reviews are immediately queued and assigned a unique batchId. Background workers automatically categorize sentiment and group recurring complaints into defect candidates, accessible in Bug Tracker and Analytics.

2

Authentication & Key Management

The krend-js client expects your live API key during initialization. Configure your key via environment variables in production.

Client Configuration:
import { Krend } from "krend-js";

const krend = new Krend({
  apiKey: process.env.KREND_API_KEY!, // Required: krend_live_...
  timeoutMs: 10000,                  // Optional: Request timeout (default: 15000ms)
  maxRetries: 3,                      // Optional: Automated backoff retries (default: 3)
});

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.
3

SDK Method Reference: krend.reviews

krend-js v1.1.0

The krend.reviews namespace exposes high-level helpers to ingest feedback singly or in batches of up to 500 reviews with full TypeScript type safety.

ReviewItem TypeScript Schema
content*string
The raw text content of the review, customer complaint, or feedback message (1 to 10,000 characters). Required for every item.
ratingnumber
Numeric satisfaction score from 1 to 5. Optional.
customer_idstring
Customer identifier in your system (1 to 128 characters). Optional.
metadataRecord<string, any>
Arbitrary JSON object for contextual metadata (e.g. platform, app version, channel, region). Stored as JSONB in Postgres.
SDK Return Object (Promise<IngestResult>)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.

4

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.

5

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"}'
6

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.
7

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 engineering issue tracking systems.

Need Technical Support?

Have questions about SDK integration, high-volume review ingestion, or custom connector setups? Contact our team directly at krenddev@gmail.com.

Contact Support