Performance & Reliability of Cobalt Intelligence API

What to Expect When You Scale to 10k Loan Applications Per Month

If you’re the CTO or Head of Risk at a lending firm processing 300+ applications a day, "API availability" isn’t just a metric—it’s your revenue stream. When an API times out at 4:45 PM on the last day of the month, your underwriting queue stalls, partners get frustrated, and deals die.

We know that alternative lenders live and die by decision speed. However, we also know that accessing Secretary of State (SOS) records is fundamentally different from pinging a credit bureau. We are querying government infrastructure that varies wildly from state to state.

Here is a transparent look at Cobalt Intelligence’s performance benchmarks, how we handle state-level instability, and how you should architect your integration for maximum resilience.

1. Response Time & Throughput

Unlike a static database, the Cobalt SOS API often performs live traversals of government websites. This means our latency is directly tied to the performance of the 50 individual state portals.

The Reality of Latency:

While we optimize connection pooling and parsing, we cannot force the Delaware Secretary of State website to load faster than it physically can.

• Cached Lookups: Sub-second to < 3 seconds.
• Live Lookups (Fast States like NY, FL): 7 – 15 seconds.
• Live Lookups (Slow States like DE, TX): 30 seconds – 2 minutes.

Throughput Capacity:

Our infrastructure supports clients ranging from small brokerages to enterprise lenders running 100,000+ lookups per month. We handle high-volume batch processing daily using a queuing system that prevents system bottlenecks.

How to Optimize for Speed:

If your workflow requires instant decisions (e.g., a pre-qualification widget on a landing page), do not force a live lookup.

1. Use the Cache: Pass liveData=false in your request. This returns data from our repository of tens of millions of records (refreshed monthly) in milliseconds.
2. Async for Accuracy: If the cache misses or you need a guaranteed real-time status for final underwriting, trigger a live call using our webhook pattern (callbackUrl) so your UI doesn't hang while waiting for a slow state.

2. Uptime & SLA Guarantees

We maintain high availability for our API endpoints, but "uptime" in the SOS world is nuanced. If the California SOS website goes down for maintenance, no provider can pull live data.

Transparency on Downtime:

• Cobalt Infrastructure: We strive for high availability on our gateway and parsing engines.
• State-Level Failures: If a state site is down or times out, we return a clear error message (HTTP 500) so you know the issue is upstream. You are not billed for these failed attempts.

Incident Response:

Our engineering team monitors state connectivity actively. As 1West’s CTO noted regarding their integration, updates and fixes—even for specific data field standardizations—are typically handled within days, with direct access to support.

Real-Time Monitoring:

You can monitor the status of your requests directly via the Cobalt dashboard.

3. Rate Limits & Throttling

We design our limits to accommodate the "bursty" nature of lending (e.g., Monday morning rushes or end-of-month pushes).

Handling Spikes:

• Normal Bursts: Bursts of 5–50+ requests at a time are queued and processed steadily without error.
• Extreme Spikes: If you hit the endpoint with hundreds or thousands of requests in a single second, you will receive an HTTP 429 (Too Many Requests) error.

Scaling Your Volume:

We do not cap your monthly success. If you exceed your plan's included lookups (e.g., you bought the 5k tier but hit 7k), we continue serving requests. You are simply billed for the overage at your standard per-lookup rate.

4. Failover & Redundancy

Relying on a single synchronous HTTP request for critical path underwriting is a risk. Lenders must build for "graceful degradation."

The retryId Pattern:

For states that take longer than ~20 seconds (common in legacy government systems), the API will not keep the connection open indefinitely. Instead, it returns a retryId.

• Your Responsibility: Your system should detect this 202 status and poll the results endpoint using the retryId until the data is ready.
• Better Approach: Use the callbackUrl parameter. We will accept the request, close the connection immediately, and POST the payload to your server once the state responds.

Infrastructure Redundancy:

Our database acts as a critical failover. If a live state search fails (site down), you can fallback to querying our cached dataset. While it may be a few weeks old, a cached record is often sufficient to verify existence and formation dates during a state outage.

"Build Your Failover Plan" Checklist:

• [ ] Implement Webhooks: Don't tie up your threads waiting 45 seconds for Delaware.
• [ ] Cache Fallback: If liveData=true fails, auto-retry with liveData=false.
• [ ] Handle 202s: Ensure your LOS can handle asynchronous responses or polling.
• [ ] Audit Logs: Store the screenshotUrl immediately; it is your proof of uptime if a partner questions a decision.

‍