Teams building customer portals, embedded CRM widgets, custom sales UIs, or product-led sales motions need a CRM they can treat as a backend service. Strkr ships a REST and GraphQL API, outbound webhooks, OpenAPI spec, and SDKs with the same data model the UI uses. See /developers for the full reference.
Teams evaluating a headless CRM are usually running one of three patterns. A product-led SaaS company that wants customer-facing portal workflow backed by the sales motion. An enterprise with a bespoke sales UI that cannot be forced into a vendor UI. A platform company embedding CRM functionality inside its own product. The pain points below are what Strkr onboarding hears on every intake call with a developer-driven team.
Most CRM APIs expose a subset of what the UI can do, often with different field names, pagination behavior, and permission scopes. Developers build custom frontends and discover the API cannot update a field, or returns a different shape than the UI. Strkr ships the API as the first interface. The UI is a consumer of the same API the developer uses. Field names, pagination behavior, permission scopes are consistent.
CRMs built for sales UIs ship rate limits sized for interactive use (100 calls per minute, 5000 per day). Product-led SaaS teams with CRM-backed customer workflows hit the cap in minutes. Strkr ships tiered rate limits sized for backend workloads with per-tenant and per-endpoint scope. Scale tier runs 10,000 calls per minute as the default with elevated limits on request.
Webhook delivery on legacy CRMs runs best-effort with no dead-letter queue and no replay. A missed webhook event is a missed state transition in a product-led flow. Strkr webhook delivery runs with at-least-once semantics, exponential backoff retry (up to 24 hours), signed payloads with HMAC, and a dead-letter queue the admin can replay from.
Many CRMs promise GraphQL and ship REST-only. For complex queries (fetch a deal with its contacts, activities, custom objects, and attachments in one call) the REST round trip hits six endpoints. Strkr ships both REST and GraphQL on the same schema. GraphQL supports introspection, Relay-style pagination, and persisted queries.
Custom object support on legacy CRMs locks to a fixed shape (one picklist field, two text fields, no relationships). Strkr ships custom objects as first-class with full relationship support, every field type (text, number, picklist, lookup, formula, rollup), inheritance, and the same API surface as native objects.
Platform companies embedding CRM for their customers need strict multi-tenant isolation. Many CRMs built as single-tenant SaaS leak state across the "tenants" because the data model is single-tenant. Strkr is multi-tenant native with per-tenant data isolation, per-tenant AI retrieval index, per-tenant audit log, and per-tenant feature flagging. Platform companies can run thousands of customer CRMs on one Strkr instance.
The surfaces below are what Strkr ships for developer-facing use. The full reference lives at /developers.
The REST API covers every object with CRUD operations, pagination (cursor-based), filtering (query-string and body-based), sorting, field selection, expansion of related objects, and bulk operations. The OpenAPI 3.1 spec publishes at /developers/openapi and powers SDK generation for TypeScript, Python, Go, Ruby, and PHP.
The GraphQL API runs on the same schema as REST with introspection enabled by default, Relay-style cursor pagination, persisted queries for performance, subscriptions over WebSockets for real-time updates, and query cost analysis to protect against expensive queries.
Outbound webhooks fire on configurable events (object created, updated, deleted, stage changed, custom trigger). Delivery runs with at-least-once semantics, HMAC signing, exponential backoff retry (up to 24 hours), and a dead-letter queue the admin can replay from through the admin console or the API.
Official SDKs ship for TypeScript, Python, Go, Ruby, and PHP. The SDKs auto-generate from the OpenAPI spec so they track every API change. Code examples cover the common patterns: authentication, bulk upsert, webhook validation, pagination, custom object manipulation.
Embeddable widgets ship for React, Vue, Svelte, and plain JavaScript. The widgets handle common CRM-adjacent UI (contact capture form, booking page, deal status widget, customer portal) with the firm branding applied. The widgets communicate with the API through signed-token authentication so the API key never lives in the browser.
Authentication supports OAuth 2.0 for user-context access, API keys for server-to-server (with scoped permissions), and signed tokens for browser-facing use (with short TTL and user-context binding). The API key management surface tracks every key with scope, last-use timestamp, and rotation reminders.
The patterns below are the shapes Strkr onboarding sees across headless deployments. Each pattern uses a different mix of the API surface.
A product-led SaaS company exposes CRM-backed workflow (billing, support, usage, renewal) to its customers through a custom portal. The portal uses GraphQL for the queries and REST for the mutations. Signed tokens handle per-customer scope. The portal looks like the product rather than like a CRM.
An enterprise with a sales motion builds a bespoke sales UI (not a vendor UI). The UI uses GraphQL for queries, REST for bulk mutations, and WebSocket subscriptions for real-time deal updates. The AI retrieval runs server-side through the Strkr AI endpoints.
A platform company (vertical SaaS, agency platform, marketplace) embeds CRM functionality inside its own product with per-customer isolation. Strkr multi-tenant architecture handles the isolation natively. The platform runs thousands of customer CRMs on one Strkr instance with billing per customer-tenant.
A field-ops app on iOS and Android uses Strkr as the CRM backend. Offline-first synchronization runs through the API. The native mobile app looks nothing like a CRM but the data model is Strkr. The Strkr Mobile app serves as a reference implementation.
A data pipeline consumes Strkr webhooks for every CRM event and routes to downstream systems (data warehouse, product analytics, finance tool, custom automation). The dead-letter queue and the replay mechanism handle the eventual-consistency guarantees downstream systems need.
An AI application grounds its responses in the CRM data through Strkr retrieval endpoints. The retrieval runs on the same AI index Strkr AI uses natively with HNSW indexing and sub-100-millisecond lookups. The application layer runs the LLM orchestration while Strkr serves the retrieval layer.
Strkr AI exposes as endpoints for developers to use in their own applications. The retrieval, the drafting, and the summarization are available through the API. The buyer never picks a model and never configures a provider.
The retrieval endpoint accepts a query and returns top-N relevant records from the CRM memory (deals, contacts, documents, call summaries, email threads) with similarity scores. HNSW indexing delivers sub-100-millisecond lookups on indexes up to 1 million records.
The drafting endpoint accepts a prompt and a context (deal ID, contact ID, custom object ID) and returns a drafted response grounded in the firm voice. The firm voice learns from the first 20 approved drafts. The endpoint is model-agnostic from the developer side.
The summarization endpoint accepts a text input (call transcript, meeting notes, email thread) and returns a two-sentence summary with action items extracted. The summary respects the CRM context passed in.
The classification endpoint accepts a text input and a taxonomy and returns the most-likely label with confidence score. Taxonomies configure through the admin console (intent, product category, support priority, lead quality).
The extraction endpoint accepts a text input and a schema and returns the structured extraction. Common patterns: contract term extraction, invoice line extraction, meeting action-item extraction.
Every AI call logs with timestamp, user context, model class, and cost. The admin console surfaces cost by endpoint, by user, by model class, by tenant for platform embeds. The audit log captures every AI call for compliance review.
A general CRM retrofits an API over a UI. The comparison below is Strkr headless posture versus a typical CRM API treated as a secondary surface.
| Feature | Strkr | General CRM with retrofit API |
|---|---|---|
| API as first interface | API-first design, UI consumes API. | UI-first with API subset. |
| GraphQL support | Full schema with introspection and subscriptions. | REST-only or feature-flag GraphQL. |
| Rate limits for backend workloads | 10,000 calls per minute default on Scale. | 100 calls per minute typical. |
| Webhook reliability | At-least-once, DLQ, replay. | Best-effort, no DLQ. |
| Multi-tenant native | Per-tenant isolation at every layer. | Bolted-on tenancy with leaks. |
| Custom objects full-featured | Every field type, relationships, inheritance. | Fixed shape, no relationships. |
| Embeddable widgets | React, Vue, Svelte, plain JS. | No embed support. |
| AI endpoints for developers | Retrieval, drafting, summarization, extraction. | UI-only AI features. |
| Flat per-seat pricing | Starter 29, Pro 59, Scale 119. | Per API call plus per seat typical. |
The playbooks below are patterns Strkr onboarding sees across developer-driven deployments.
A product-led SaaS company at 60 employees built a customer portal exposing billing, support, usage, and renewal workflow backed by Strkr. The portal used GraphQL for queries and REST for mutations with signed tokens. The portal shipped in 11 weeks of engineering time. CRM functionality lived inside the product rather than as a sales-only tool.
A 180-rep enterprise ran a bespoke sales UI tailored to their specific motion. The current CRM UI could not be forced into the shape they needed. Strkr onboarding ran a 42-business-day migration treating Strkr as a backend service. The bespoke UI used GraphQL subscriptions for real-time deal updates. The CRM backend ran at a quarter of the licensed cost of the previous vendor.
An agency platform embedding CRM functionality for its 480 agency customers used Strkr multi-tenant architecture to run 480 customer CRMs on one Strkr instance. Per-customer billing ran through the platform. The platform shipped CRM functionality in six weeks instead of twelve months of in-house build.
A field ops company built a native iOS and Android app for 240 technicians using Strkr as the CRM backend. The app looked nothing like a CRM but the data model was Strkr. Offline-first synchronization through the REST API handled jobsite connectivity. The build-vs-buy decision ran six months of engineering time, not two years.
An AI startup building a sales-coaching application grounded responses in the Strkr retrieval endpoints. HNSW-indexed retrieval delivered sub-100-millisecond lookups on tenant memory. The AI application ran the LLM orchestration while Strkr served the retrieval layer. Time-to-market compressed from twelve months to four.
Book a 30 minute call. We will walk through the REST and GraphQL surfaces, the webhook delivery guarantees, and the multi-tenant architecture with your actual use case. For the full developer reference see /developers.
Strkr ships tiered rate limits scaled by subscription tier and workload type. Starter runs 1,000 calls per minute per tenant. Pro runs 5,000 calls per minute per tenant. Scale runs 10,000 calls per minute per tenant with elevated limits available on request for specific high-volume workloads. Rate limits apply per endpoint class (read-heavy, write-heavy, AI-heavy) so a product-led flow does not starve the sales UI. The headers return remaining-quota and reset-time for backend throttling.
Webhook delivery runs with at-least-once semantics, HMAC signing with per-tenant secrets, exponential backoff retry (initial retry at 30 seconds, max retry at 24 hours), and a dead-letter queue after retry exhaustion. The DLQ exposes through the admin console and the API. Replay runs on a single event or a time range. For developers building production workloads the recommended pattern is to accept-and-queue on the webhook endpoint, so the webhook returns 200 quickly and the downstream processing runs asynchronously.
Yes. GraphQL subscriptions run over WebSockets with per-tenant isolation. Developers subscribe to object changes (deal updated, contact added, custom object transition) with GraphQL query filters applied. The subscription delivery runs with at-least-once semantics within the WebSocket session. For reconnection and backfill the recommended pattern is to combine subscriptions with periodic polling of a modified-since cursor.
Multi-tenant isolation at Strkr runs at every layer: the database (per-tenant row-level security policy on every table), the compute (per-tenant Lambda invocation context), the AI retrieval index (per-tenant HNSW index), the audit log (per-tenant log stream), and the file storage (per-tenant S3 prefix). API keys scope per-tenant. Signed tokens bind to tenant-plus-user. For platform companies embedding Strkr the tenant abstraction maps to the platform customer with billing attribution running through the platform.
Strkr prices flat per seat at 29 on Starter, 59 on Pro, and 119 on Scale per user per month, with a 14-day trial. The API, GraphQL, webhooks, SDKs, and embeddable widgets are included at every tier. A self-built CRM backend typically runs 6 to 18 months of engineering time (1.2 million to 3.6 million at loaded engineering cost). A general CRM API with per-call pricing (Salesforce API, Microsoft Dataverse) typically runs 180 to 400 per user per month on the API-heavy edition plus per-call overages. Strkr sits well below both approaches.
Strkr is HIPAA compliant with a BAA available on request (relevant for health-tech platform embeds), GDPR and CCPA compliant today, and SOC 2 Type II is in progress with a target of 2026-Q4. For developers the compliance posture extends to the API, GraphQL, webhooks, and AI endpoints with the same guarantees as the native UI. Integration tokens live in AWS KMS with per-tenant scope. The audit log captures every API call with 90-day default retention tunable per tenant. See /developers for the full technical reference.
No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.
