Most CRMs ship an API as an afterthought with rate limits that punish real workloads and documentation that stops at the first custom object. Strkr ships REST, GraphQL, and webhook surfaces as first-class capability with a published OpenAPI spec and flat per-seat pricing that does not scale with API call volume.
A developer evaluating a CRM for an integration project reads the API docs first. If the API docs are shallow, gated behind sales, or buried under enterprise plan upsell messaging, the developer bounces. The pain points below are what Strkr hears on every developer evaluation call.
A typical CRM API doc covers the five default objects (account, contact, lead, deal, opportunity) with example requests. Custom objects, custom fields, and custom workflows live behind sales. The developer evaluating the integration cannot see the full surface without a 30-minute sales call. Strkr publishes the full OpenAPI spec covering every custom object, every field, and every workflow trigger with example requests and responses.
A typical mid-market CRM API caps at 100 to 500 requests per minute. A real integration workload runs 20,000 to 50,000 requests per hour at steady state. The developer builds a complex queuing layer just to stay under the rate limit. Strkr caps at 1,000 requests per minute on Pro and 2,500 requests per minute on Scale with burst allowance of 2x the baseline for 60-second windows.
A typical CRM webhook ships with three retry attempts, no HMAC signing, and no reconciliation API for missed deliveries. The developer builds a reconciliation job that polls the full dataset once an hour to catch missed webhooks. Strkr webhooks ship with 10-retry exponential backoff, HMAC-SHA256 signing with timestamped headers, and a reconciliation API that returns delivery state for any time window.
A typical mid-market CRM gates GraphQL behind enterprise pricing or ships only REST. The developer either accepts the N+1 request pattern on REST or budgets for the enterprise tier. Strkr ships GraphQL alongside REST on every paid tier with the same rate limit allocation and the same OpenAPI documentation standard.
A typical mid-market CRM ships one production tenant with no distinct test environment. The developer either tests in production (a bad practice) or pays for a second subscription just for staging. Strkr ships a dedicated sandbox environment on every tenant with isolated data and the same API surface so the developer can run CI integration tests against a real Strkr instance.
A typical mid-market CRM meters API calls past a floor at $0.001 to $0.01 per call. A real integration workload runs the invoice from $200 per month to $4,000 per month inside a quarter. Strkr prices flat per seat with no API call meter. The invoice math is predictable and the developer can scale integration workloads without finance intervention.
Strkr ships the API as a first-class surface, not an afterthought. The cards below are what a developer sees when they open the Strkr developer documentation on day one with a trial tenant.
The REST surface covers CRUD operations on every object (contact, deal, account, custom objects, notes, activities, documents, workflows) with filtering, sorting, and pagination. Field selection reduces payload size. Bulk operations handle up to 500 records per request on Pro and 2,000 on Scale.
The GraphQL endpoint covers the same object graph as REST with the standard query, mutation, and subscription operations. The subscription endpoint uses WebSocket for real-time updates. The schema introspection endpoint returns the full type graph which lets the developer code-generate client bindings in TypeScript, Python, Go, or Rust.
Outbound webhooks fire on every record create, update, delete, and workflow trigger. Each delivery includes an HMAC-SHA256 signature with timestamp. Failed deliveries retry on exponential backoff up to 10 times. The reconciliation API returns delivery state for any time window so the developer can catch missed deliveries without polling the dataset.
The OpenAPI 3.1 spec publishes at a stable URL covering every endpoint, every parameter, every response type, and every error code. The spec drives client code generation in every major language. The developer can import the spec into Postman, Insomnia, or an OpenAPI client library and have a working integration shell in minutes.
Every tenant ships a sandbox environment with isolated data and the same API surface. The developer can run CI integration tests against a real Strkr instance without touching production data. The sandbox refreshes on demand from a snapshot of production data (with PII masked) so the test fixtures stay realistic.
Pro tier caps at 1,000 requests per minute with burst to 2,000 for 60 seconds. Scale tier caps at 2,500 per minute with burst to 5,000. The response headers include rate limit remaining, limit reset time, and burst state so the developer can implement adaptive throttling without guessing. Rate limit violations return 429 with a Retry-After header.
Beyond the API surface Strkr ships extension capability for custom workflows, custom objects, custom reports, and custom UI panels. The developer can extend Strkr without forking the codebase or waiting for a product release cycle.
Custom objects let the developer or admin define new record types with fields, relationships, workflow triggers, and permission scopes. For an industry vertical where the default CRM schema does not fit (legal matters, dental treatment plans, factoring deals) the custom object surface replaces custom development work.
The flow builder exposes workflows as declarative DAGs with 140-plus action types across CRUD operations, email, Strkr Messaging SMS and MMS, Slack, Teams, webhooks, waits (duration, condition, approval), and branch logic. The developer can compose complex automation without writing code. For patterns that require code the webhook action calls out to any HTTP endpoint.
The report builder lets the developer or analyst compose reports against the live schema with filters, groupings, aggregations, and visualizations. The underlying query engine translates to materialized rollups for performance. Reports export to CSV or JSON and can embed in external dashboards through signed URL.
The permission system scopes on 54 resource types with role templates and custom role capability. Field-level permissions ship inside the Layouts module (pre-launch) with visibility, read-only, and hidden states per role per field. The policy covers both UI render and API read endpoint, which means a hidden field never leaks through a direct API call.
The audit log API exposes every record read, record write, email send, document access, and AI call with user, timestamp, source IP, and context. The developer can stream the log to Splunk, Datadog, Elastic, or Panther for downstream SIEM correlation. The log is append-only within the retention window with signed export manifest for integrity verification.
Strkr infrastructure runs on append-only Pulumi route arrays with deterministic esbuild bundles. The engineering team ships new endpoints without rebuilding or redeploying unrelated Lambdas. The developer integrating against Strkr gets stable endpoint URLs with new capability added at the edge rather than through breaking URL changes.
A developer evaluation runs on details: SDKs, errors, pagination, retry semantics, documentation quality. The cards below are what the Strkr developer experience ships as default.
Official SDK libraries ship in TypeScript, Python, Go, Ruby, and PHP with full OpenAPI code generation and manual ergonomic wrappers for common patterns (pagination, retry, HMAC webhook verification). Community-contributed SDKs for Rust, Elixir, and Java live on GitHub with the Strkr repository.
Every error response returns a structured JSON body with specific error code (not just HTTP status), human-readable message, and documentation URL for the error type. The developer can map errors to specific handling logic without parsing error strings. The error code taxonomy is stable across API versions.
Pagination runs on opaque cursor tokens rather than offset. The cursor approach stays stable even when the underlying data changes mid-pagination, which matters for integration jobs that run across minutes or hours. The response includes next and previous cursor tokens with the result count hint.
Every write operation accepts an idempotency key in the request header. Strkr deduplicates requests with the same key within a 24-hour window. The developer can safely retry on timeout or network failure without creating duplicate records. The idempotency pattern follows Stripe convention which most developers already know.
API versions use date headers (API-Version: 2026-10-01) with new versions published quarterly. Deprecated versions remain available for 24 months with upgrade documentation. Breaking changes always ship as new versions. The developer can pin to a version and migrate on their own schedule without surprise breakage.
The Strkr changelog documents every API addition, change, and deprecation with publication date and version number. The status page at status-prod.strkr.io shows real-time service health across six components (API, dashboard, webhooks, email, messaging, auth). The developer can subscribe to incident notifications through the status page.
The comparison below is Strkr API posture versus the typical mid-market CRM API that a developer evaluates for integration work.
| Feature | Strkr | Typical mid-market CRM API |
|---|---|---|
| REST endpoints published | Full OpenAPI 3.1 spec at stable URL. | Developer portal with incomplete coverage. |
| GraphQL endpoint | Included on every paid tier. | Enterprise tier typical gate. |
| Rate limit baseline | 1000 per minute Pro, 2500 Scale. | 100 to 500 per minute typical. |
| Webhook retry policy | 10 retries exponential backoff. | 3 retries typical. |
| Webhook HMAC signing | HMAC-SHA256 with timestamped header. | Varies, often none. |
| Sandbox environment | Included on every tenant. | Separate subscription typical. |
| API price | Flat per seat, no API meter. | Metered past floor. |
| SDK libraries | Five official languages. | One or two typical. |
| Idempotency keys | Supported on all writes. | Varies. |
The playbooks below are what Strkr onboarding sees across developer-driven integration deployments.
A 14-person engineering team at a usage-based SaaS vendor needed to tie product usage telemetry to CRM account records for CSM health scoring. The engineering team wired four product usage webhooks (daily active users, feature adoption, API volume, admin seat activity) into the Strkr webhook spec. The integration shipped in an engineering sprint of six business days. The CSM health scores updated hourly with real usage data.
A 90-rep enterprise manufacturer needed deep quote-to-cash integration between Strkr and NetSuite. The engineering team wired bi-directional sync (quote creation, approval, order placement, invoice generation, payment status) across both systems using the GraphQL mutation surface on Strkr and the SuiteScript surface on NetSuite. The integration shipped in a four-week engineering sprint. The sales team closed quotes 42 percent faster with the integrated flow.
A boutique legal services firm needed a custom CRM frontend tailored to a litigation workflow that did not fit the default Strkr UI. The engineering team built a custom frontend using React consuming the Strkr GraphQL endpoint. The custom frontend handled 85 percent of the day-to-day workflow with the Strkr default UI as fallback for admin functions. The engineering sprint ran eight weeks. The specialty workflow efficiency climbed 48 percent.
A 60-person vertical SaaS company serving dental practices embedded CRM capability inside their primary SaaS product. The engineering team used Strkr as the CRM backend accessed through the API with white-label branding and SSO integration. The embedded experience shipped in a six-month engineering sprint. The vertical SaaS added CRM capability to their product line without rebuilding the CRM layer from scratch.
A public SaaS company engineering team needed to stream the Strkr audit log to a central SIEM (Splunk Enterprise) for cross-system correlation. The engineering team wired the audit log API to a Lambda function that polled every five minutes, transformed to CEF format, and shipped to Splunk via HEC. The integration shipped in a two-week engineering sprint. The security team gained CRM audit visibility in the central SIEM dashboard.
Start a trial tenant and read the full OpenAPI spec on day one. The developer surface activates immediately with sandbox access and SDK downloads. Book a 30 minute call to walk through your integration architecture with a Strkr engineer.
The Strkr OpenAPI 3.1 spec publishes at a stable URL under /openapi.json on every tenant. The developer documentation at /developers covers REST, GraphQL, webhook, and SDK reference with example requests and responses for every endpoint. For a trial tenant the full developer surface activates on day one at no additional cost. The developer can run the full OpenAPI spec through Postman, Insomnia, or OpenAPI client generators to produce code bindings in TypeScript, Python, Go, Ruby, PHP, or any OpenAPI-supported language.
Pro tier caps at 1,000 requests per minute steady-state with burst to 2,000 for a 60-second window. Scale tier caps at 2,500 steady-state with burst to 5,000. The burst allowance uses a leaky-bucket algorithm so a burst spends from a credit pool that refills at the steady-state rate. The response headers include rate limit remaining, limit reset time, and burst credit remaining so the developer can implement adaptive throttling without guessing. Rate limit violations return HTTP 429 with a Retry-After header indicating the retry window.
Strkr API authentication uses API keys for machine-to-machine integration and OAuth 2.0 for user-authorized access. For enterprise identity flows the OAuth 2.0 bearer token issued by the tenant SSO provider (SAML or OIDC via Clerk on Scale tier) authenticates against the API. The API key approach supports fine-grained scoping (read-only, read-write, admin, specific object types) and rotation on a 90-day cadence. The developer can generate scoped keys programmatically through the admin API.
The webhook reconciliation API accepts a time window query and returns the delivery state for every webhook event in that window with status (delivered, retrying, failed, pending). For missed deliveries the developer can request redelivery through the reconciliation API without reprocessing from the full dataset. The reconciliation window covers 30 days by default and tunes up to 90 days on Scale. The approach replaces the common polling loop that most teams build to catch missed webhooks.
Official SDK libraries ship in TypeScript, Python, Go, Ruby, and PHP with full OpenAPI code generation and manual ergonomic wrappers for common patterns. Community-contributed SDKs for Rust, Elixir, and Java live on GitHub. Each SDK releases on the quarterly API version cadence (new version date-stamped quarterly) with backward compatibility maintained for 24 months on deprecated versions. The SDK repositories live on GitHub with the Strkr organization and accept community contributions through standard pull request flow.
API versions use date-based headers (API-Version: 2026-10-01) with new versions published quarterly. Breaking changes always ship as new versions, never as changes to existing versions. Deprecated versions remain available for 24 months after the deprecation notice with full documentation and migration guides. The changelog publishes every API addition, change, and deprecation with publication date. The developer can pin an integration to a version and migrate on their own schedule without surprise breakage.
No. API calls run flat per seat with no additional metered billing. A 10-rep team on Pro at $590 per month gets the full API surface with 10,000 requests per minute aggregate capability (1,000 per seat scales linearly). Teams that run 20,000 to 50,000 requests per hour at steady-state integration workloads stay within the baseline on Pro. Teams running 100,000 requests per hour or more typically land on Scale tier for the 2,500 per minute per seat baseline and the extended burst allowance.
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.
