Forem: Dawid Makowski

Laravel Response Cache Serving Wrong Language: Fixing spatie/laravel-responsecache with mcamara/laravel-localization

Dawid Makowski — Sun, 19 Apr 2026 05:44:34 +0000

If you're running a multilingual Laravel site with mcamara/laravel-localization and spatie/laravel-responsecache, your response cache might be serving the wrong locale to visitors. Here's how we diagnosed and fixed a bug where our English site kept getting cached in Chinese.

The Problem: Laravel Multilingual Site Cache Stuck on Wrong Language

About once a day, our production Laravel 12 site started serving Chinese content to all visitors. The homepage, blog posts, service pages - everything rendered in Simplified Chinese instead of English. The only fix was clearing the response cache manually:

php artisan responsecache:clear

Content would go back to English... until the next day when it flipped to Chinese again.

Our Multilingual Laravel Stack

Laravel 12 with mcamara/laravel-localization for URL-prefixed i18n (/en/blog, /zh/blog, /de/blog)
spatie/laravel-responsecache for full-page HTML caching (7-day TTL) using DefaultHasher
Six supported locales including zh (Chinese Simplified)
hideDefaultLocaleInURL set to false -- all URLs have an explicit locale prefix

Root Cause: Why spatie/laravel-responsecache Ignores the Locale

The response cache stores rendered HTML keyed by a hash of the request URL. Since our URLs include locale prefixes (/en/blog vs /zh/blog), each locale should get its own cache entry. So how was Chinese content leaking into English pages?

Three things were conspiring against us.

1. `useAcceptLanguageHeader` Overrides URL Locale During Route Resolution

In config/laravellocalization.php, there's this setting:

'useAcceptLanguageHeader' => true,

This tells mcamara/laravel-localization: "If you can't determine the locale from the URL, check the browser's Accept-Language header."

Sounds reasonable. But LaravelLocalization::setLocale() runs during route resolution on every request. When the URL segment doesn't contain a recognized locale (e.g., a request to /), it calls getCurrentLocale() as a fallback:

public function getCurrentLocale()
{
    if ($this->currentLocale) {
        return $this->currentLocale;
    }

    if ($this->useAcceptLanguageHeader() && !$this->app->runningInConsole()) {
        $negotiator = new LanguageNegotiator(...);
        return $negotiator->negotiateLanguage();
    }

    return $this->configRepository->get('app.locale');
}

When a Chinese bot (Baidu, Sogou, etc.) hits the root URL / with Accept-Language: zh, the negotiator returns zh, and app()->setLocale('zh') is called as a side effect during route resolution. The page renders in Chinese, gets cached, and every subsequent visitor to that URL sees Chinese content until the cache expires or is cleared.

2. Spatie's `DefaultHasher` Doesn't Include Locale in the Cache Key

The DefaultHasher in spatie/laravel-responsecache generates cache keys like this:

return 'responsecache-' . hash('xxh128',
    "{$request->getHost()}-{$request->getPathInfo()}-{$request->getMethod()}/{$suffix}"
);

The active locale is only present implicitly through the URL path. If any edge case causes app()->getLocale() to return the wrong locale during rendering, the wrong HTML gets cached under the "correct" URL's key. There's no defense-in-depth -- the DefaultHasher trusts that the URL path and the active locale always agree.

3. Synchronous `Artisan::call()` in Model Observers Mutates Locale State

Our ClearResponseCacheObserver did this on every model update :

protected function refreshSite(Model $model): void
{
    ResponseCache::clear();           // Nuke the entire cache
    Artisan::call('generate-sitemap'); // Runs synchronously!
    $this->submitToIndexNow($model);  // Notify search engines
}

The sitemap command calls LaravelLocalization::setLocale('en') internally, mutating the application locale during the active web request. Then submitToIndexNow notifies search engines (including Chinese ones) about all locale URLs via IndexNow, and their bots come crawling within seconds - while the response cache is still empty after the clear.

The Fix: Three Changes to Make Laravel Response Cache Locale-Aware

Fix 1: Custom Locale-Aware Hasher for `spatie/laravel-responsecache`

We created a custom hasher that extends DefaultHasher and explicitly includes app()->getLocale() in every cache key:

<?php

declare(strict_types=1);

namespace App\Http\CacheProfiles;

use Illuminate\Http\Request;
use Spatie\ResponseCache\Hasher\DefaultHasher;

class LocaleAwareHasher extends DefaultHasher
{
    public function getHashFor(Request $request): string
    {
        $cacheNameSuffix = $this->getCacheNameSuffix($request);
        $locale = app()->getLocale();

        return 'responsecache-'.hash(
            'xxh128',
            "{$request->getHost()}-{$this->getNormalizedRequestUri($request)}-{$request->getMethod()}-{$locale}/{$cacheNameSuffix}"
        );
    }
}

'hasher' => \App\Http\CacheProfiles\LocaleAwareHasher::class,

Now even if the URL says /en/blog but app()->getLocale() somehow returns zh, they get separate cache entries instead of one overwriting the other. This makes locale cache contamination structurally impossible.

Fix 2: Disable `useAcceptLanguageHeader` in `mcamara/laravel-localization`

// config/laravellocalization.php
'useAcceptLanguageHeader' => false,

Since all our URLs have explicit locale prefixes (/en/, /zh/, etc.), there's no need for Accept-Language header detection. With this disabled, requests without a locale prefix fall back to the default app locale (en) instead of negotiating from whatever language a bot's headers specify.

This was the core trigger. One config line that let Chinese bots poison the response cache through the Accept-Language header.

Fix 3: Move Sitemap Generation to a Queued Job

We replaced the synchronous Artisan::call('generate-sitemap') in the model observer with a queued job:

// app/Jobs/GenerateSitemapJob.php
class GenerateSitemapJob implements ShouldQueue
{
    public function handle(): void
    {
        Artisan::call('generate-sitemap');
    }
}

// In the observer:
protected function refreshSite(Model $model): void
{
    ResponseCache::clear();
    GenerateSitemapJob::dispatch(); // Runs in isolated queue worker
    $this->submitToIndexNow($model);
}

The sitemap command's LaravelLocalization::setLocale('en') call now runs in an isolated queue worker process.

How to Check If Your Laravel App Is Affected

You're likely vulnerable to this response cache locale bug if:

useAcceptLanguageHeader is true in config/laravellocalization.php
You're using DefaultHasher (the default) in config/responsecache.php
You have non-Latin locales enabled (Chinese, Arabic, etc.) that make the bug immediately visible
You're using spatie/laravel-responsecache with mcamara/laravel-localization together

Don't Forget: Clear Response Cache After Deploy

Since the cache key format changes with the new LocaleAwareHasher, you must clear the existing response cache after deploying:

php artisan responsecache:clear

Vibe Code Rescue: Turn Your AI-Built Prototype Into a Product That Can Actually Scale

Dawid Makowski — Thu, 09 Apr 2026 15:09:54 +0000

At a certain point you need professional engineering discipline, not more prompting.

That is exactly where A2Z WEB's Vibe Code Rescue comes in. In a focused, time-boxed engagement, our senior engineers and CTOs audit your code, stress-test your infrastructure, surface vulnerabilities, and hand you a prioritized roadmap to get scale-ready. You walk away with total clarity on the real health of your product, and a credible plan to fix it.

Who this is for

You should keep reading if any of this sounds familiar:

You (or a non-technical co-founder) shipped your MVP using Cursor, Claude, Lovable, Bolt, v0, Replit, GitHub Copilot, or a similar AI-first workflow.
Real users are now in the product, and every new feature seems to break two old ones.
You suspect there are security holes, but nobody on the team can confidently say where they are.
Your cloud bill is climbing faster than your revenue.
Investors, enterprise customers, or a partner just asked about security, uptime, or architecture, and you froze.
You are about to hire your first engineers and you want them to inherit a codebase they will not immediately want to throw away.

If you nodded at two or more of those, your product has hit the limit of what vibe coding alone can deliver. That is not a failure. It is a predictable inflection point, and it has a predictable fix.

What "vibe coded" really leaves behind

Speed has a price, and AI-generated codebases tend to pay it in the same places every time. In a typical Vibe Code Rescue we find:

Security holes nobody designed in. SQL injection, broken authentication and session handling, exposed API keys, missing authorization checks, public storage buckets, leaky logs, and personal data sitting in places it should never be.
Architecture held together by duct tape. Business logic copy-pasted across screens, state managed in five different ways, no clear boundary between frontend and backend, and database schemas that quietly assume nothing will ever change.
Fragile, unrepeatable deployments. No environments, no migrations, no rollbacks, no CI, no real version control discipline. "It works on prod" because prod is the only place it has ever worked.
Zero test coverage. Every shipment is a coin flip. Regressions are discovered by users, not by the team.
Cloud spend on autopilot. Oversized instances, forgotten dev environments, chatty AI calls with no caching, storage that nobody is cleaning up. Your infrastructure invoice is a tax on guesswork.
A codebase no human can confidently change. New features take longer every week because nobody fully understands what is already there, including the AI that wrote it.

None of this means the AI did a bad job. It means the AI did exactly what it was asked to do: make it work, fast. Making it safe, scalable, maintainable, and affordable is a different job, and it needs different people.

The Vibe Code Rescue, step by step

We run the engagement as a structured, two-week sprint led by a senior CTO and a small team of senior engineers. Every line of analysis is done by a real human, supported (not replaced) by industry-standard tooling.

Week 1: See the truth

1. Discovery and goal setting. A working session with you and your team to align on what the product is supposed to do, who is using it, what is on fire, and what success looks like in 6 and 12 months. We write it down so we are auditing against your reality, not a generic checklist.

2. Codebase analysis. We run your repository through industry-standard static analysis, dependency scanning, and code quality tooling, then a senior engineer walks the code by hand. You get hard data on technical debt, code quality, dead code, dependency risk, license risk, and structural weaknesses, with concrete file and line references.

3. Architecture review. We map how your system is actually built today: services, data flows, integrations, third-party dependencies, AI calls, and failure points. We compare that map against where you want to be in 12 months and flag the gaps that will hurt you first.

4. Security testing. A focused application security review covering the OWASP Top 10 and the issues we see most often in AI-generated codebases: SQL and NoSQL injection, authentication and session weaknesses, broken access control, data exposure, secrets in source, insecure file handling, vulnerable dependencies, CORS and CSRF issues, and personal data handling. Where it is safe to do so, we demonstrate how easy each issue is to exploit, so the risk is undeniable.

5. Load and resilience testing. We push your system until it breaks, in a controlled environment, so you know exactly how much traffic your product can handle, where it falls over first, and how it behaves under failure. No more guessing whether you can survive a launch, a Product Hunt spike, or a single big customer.

Week 2: Get a plan you can actually execute

6. Cloud and cost audit. We review your cloud setup (AWS, GCP, Azure, Vercel, Supabase, Render, Fly, and friends), look at how much you are spending and where, and identify quick wins and structural changes that bring the bill back under control without sacrificing performance.

7. AI usage review. If your product calls LLMs or other AI APIs, we review prompts, model choices, caching, retries, guardrails, evaluation, and cost per request. AI features should be reliable line items, not surprises at the end of the month.

8. Prioritized remediation roadmap. Everything we found is consolidated into a single, ranked action plan. Each item has a clear severity, an estimate of effort, an owner profile (who should do it), and a recommended sequence. Critical security and stability issues come first; long-term refactors come later, with a clear story of why.

9. Executive readout. A live walkthrough with you and, if you want, your investors, board, or key customers. Plain language, no jargon, no defensiveness. You finish the call knowing exactly where you stand and what to do on Monday morning.

What you walk away with

Every Vibe Code Rescue concludes with a concrete, written package, not a verbal "you should probably refactor things":

A full Technical Health Report covering code quality, architecture, security, performance, infrastructure, and cost.
A Security Findings Report with severity, evidence, exploitability, and remediation guidance for each issue.
A Load and Resilience Report with measured breaking points, bottlenecks, and recommendations.
A Cloud Cost Review with itemized savings opportunities and projected monthly impact.
A Prioritized Remediation Roadmap for the next 30, 60, and 90 days, plus a longer-term architecture direction.
An Executive Summary & Live Readout — a plain-language brief you can share with non-technical stakeholders, investors, and enterprise buyers, delivered in a working call with the senior team that did the work.

Everything is yours to keep, share, and act on, with or without us.

Why A2Z WEB

We are not a generic agency that "also does audits." Vibe Code Rescue is delivered by the same senior CTOs and engineers who run our CTO as a Service, Tech Auditing and Strategy Consulting, Custom Software Development, AI Automation, and Cloud Cost Optimization Audit practices for funded startups and established companies.

A few things that matter:

Senior people only. No juniors quietly billed at senior rates. Every audit is led by a CTO-level engineer who has shipped, scaled, and rescued real products.
Practical, fact-based recommendations. We translate between business priorities and technical reality, so your decisions rest on data, not vibes (pun intended).
AI-fluent, not AI-naive. We use the same AI tools your team uses. We know exactly what they are good at, where they cut corners, and how to clean up after them.
SOC 2 aligned process. Your code, data, and findings are handled with the same security discipline we expect from your product.
A real path forward. When the audit is done, we can hand the roadmap back to your team, work alongside them, or take ownership of the remediation as a fractional engineering team. Your call.

The "no surprises" guarantee

If, at the end of the engagement, you do not feel you have a clearer, more honest picture of your product than you did when you started, we will refund the engagement fee. We can promise that because we have never had to.

Frequently asked questions

How long does it take?
Two weeks from kickoff to executive readout. We can move faster for urgent situations (pre-launch, due diligence, security incident); ask us.

Do we need to pause feature work?
No. The audit runs in parallel with your normal development. We will need a few hours of your team's time across the two weeks, mostly for kickoff, questions, and the readout.

Will you need access to production?
We work in a read-only mode by default, against a staging environment or a snapshot, and we agree on every access scope in writing before we touch anything. Nothing destructive happens without your explicit approval.

What stack do you cover?
TypeScript and JavaScript (Node, Next.js, React, Vue, Svelte), Python (Django, FastAPI, Flask), Ruby on Rails, PHP (Laravel), Go, mobile (React Native, Flutter, Swift, Kotlin), and the usual cloud and database suspects (AWS, GCP, Azure, Vercel, Supabase, Postgres, MySQL, MongoDB, Redis). If you are on something more exotic, ask us; we have probably seen it.

What if the audit finds something really bad?
Then you will be glad you ran it now instead of after the breach, the outage, or the failed enterprise security review. We will help you triage and, if you want, fix it.

Can you also build the fixes?
Yes. After the audit you can engage A2Z WEB as a fractional engineering team, a CTO as a Service partner, or a full custom development team, depending on what you actually need.

How much does it cost?
A fixed fee for the two-week engagement, agreed upfront, with no hidden extras. We will quote it on the intro call once we understand the size and shape of your product. It is meaningfully less than the cost of the first serious incident it will prevent.

Ready to find out what your product is really made of?

Book a 30-minute, no-pressure intro call. We will ask a handful of questions about your product, your stack, and what is keeping you up at night, and tell you honestly whether a Vibe Code Rescue is the right next step.

Book your intro call

Your AI got you to v0.1. Let us help you get the rest of the way.

Smarter Scoring, Sharper Hiring: A Major Update to the CV Match Score API

Dawid Makowski — Thu, 09 Apr 2026 11:42:04 +0000

We've just shipped one of the most requested improvements to the Resume/CV & Job Description Compatibility Scoring endpoint. If you're building ATS integrations, candidate-screening tools, or HR analytics dashboards on top of SharpAPI, this update unlocks a whole new level of control over how matches are scored.

Here's everything that's new, why it matters, and how to start using it today.

TL;DR

The context parameter is now a formal directive contract, not a free-form note.
You get three simple directive shapes: EMPHASIZE, DEEMPHASIZE, and CREDIT.
Directives now influence the overall_match score — not just the individual metrics.
Role-family standard credentials (think Excel / SQL / Power BI for finance roles) are credited automatically even when the job description forgets to mention them.
Maximum context length is formally set to 5000 characters.

👉 Jump straight to the product page: sharpapi.com/en/catalog/ai/hr-tech/resume-cv-job-match-score

The problem we were solving

When we first launched the CV Match Score endpoint, it scored every resume against every job description using a fixed weighting table: skills, experience, and technical stack at the top; education, certifications, and soft skills as supporting signals. That works beautifully for the average hiring scenario — but hiring is never average.

A startup hiring a fresher values education and credentials far more than ten years of experience. A contract-hiring desk cares about skills, not tenure. A remote-first company doesn't want location pulling the score down at all. And sometimes, the job description simply forgets to list the obvious credentials — like Excel for a finance analyst — leaving the scoring engine to assume they don't matter.

Customers kept asking the same question:

"How do we tell the engine that **for this role, education matters more than experience?"

Now you can.

✨ What's new

1. A formal directive contract for the `context` parameter

The context field already existed, but its behaviour was fuzzy — long prose instructions often had unpredictable effects. We've replaced that with a clean, predictable contract built around three directive shapes.

Directive	What it does	Example
🔼 `EMPHASIZE: <topic>`	Increases the weight of the matching metric(s) by one step	`EMPHASIZE: skills`
🔽 `DEEMPHASIZE: <topic>`	Decreases the weight of the matching metric(s) by one step (never zero)	`DEEMPHASIZE: experience`
➕ `CREDIT: <skill \	tool \	cert>`

Directives can be mixed freely in a single context string:

EMPHASIZE: skills. EMPHASIZE: education. DEEMPHASIZE: experience. CREDIT: Excel and Analytics certificates.

You don't need to memorise the full schema of 20 metrics, either. Topics accept plain-English categories like skills, experience, education, certificates, location, management, or tenure, and the engine maps them onto the related metrics internally.

2. `context` now moves the `overall_match` score

Before this update, the overall_match was computed from a hardcoded weighted average of the 20 individual metrics — meaning even if context shifted individual scores, the final overall number often stayed stubbornly still.

Not anymore. Directives now adjust the internal weighting table before the weighted average is computed. A single EMPHASIZE: skills now propagates all the way through to the final score.

Here's what that looks like conceptually:

Baseline weights:       skills=3, experience=3, education=1, certifications=1 ...
After EMPHASIZE: skills + DEEMPHASIZE: experience + EMPHASIZE: education:
Adjusted weights:       skills=4, experience=2, education=2, certifications=1 ...
overall_match = Σ(score × adjusted_weight) / Σ(adjusted_weights)

Same resume. Same job description. Different scoring lens. That's the magic.

3. Role-family standard credentials are now credited

Here's a real example from customer feedback:

A finance JD said "Required: Excel, Python, analytics skills" but didn't list any specific certifications. A candidate with Advanced Excel, SQL, and Power BI certifications was getting certifications_match: 0 — because the JD was silent about certs.

That's obviously wrong. Those certifications are industry-standard for finance roles, and the engine should have credited them.

With this update, when the job description doesn't enumerate required certifications but the resume lists credentials that are commonly expected for the role family, the engine now credits them proportionally in the 40–70 range, with the reasoning noted in the explanations field.

This applies across role families:

💼 Finance / analyst roles → Advanced Excel, SQL, Power BI, Tableau
👨‍💻 Software engineering → Git, CI/CD, cloud platform certs
📊 Project management → PMP, PRINCE2, Scrum, Agile
🏥 Healthcare → CPR, BLS, specialty certifications

No more zero-scores on obvious credentials just because the JD was lazy.

4. Formalised 5000-character limit on `context`

We've set a clean, generous upper bound of 5000 characters for the context field. That's comfortably above any realistic directive payload — enough room for dozens of directives plus explanatory notes — while keeping the full prompt within safe token budgets.

Requests exceeding the limit return an HTTP 422 validation error.

Recommended patterns

These are the context recipes that performed best in our internal validation. Drop them in as starting points and tune from there.

Pattern 1 — Entry-level / fresher hiring

Prioritise credentials and potential over years of experience.

EMPHASIZE: skills. EMPHASIZE: education. DEEMPHASIZE: experience. CREDIT: Excel and Analytics certificates.

Pattern 2 — Senior technical hiring

Stack match is critical; formal education is secondary.

EMPHASIZE: skills. EMPHASIZE: technical_stack_match. DEEMPHASIZE: education.

Pattern 3 — Leadership / management hiring

Management experience outweighs hands-on technical skills.

EMPHASIZE: management. EMPHASIZE: experience. DEEMPHASIZE: technical_stack_match.

Pattern 4 — Remote-first hiring

Location should not penalise candidates at all.

DEEMPHASIZE: location. EMPHASIZE: skills.

Best practices

Be specific. CREDIT: Excel, SQL, Power BI moves the needle. Abstract framing like "practical competency outweighs formal credentials" does not.
Use contrast pairs. Combine EMPHASIZE with DEEMPHASIZE in the same request — contrast is a strong signal.
Name tools and credentials explicitly. Avoid vague qualities like "talent" or "potential".
Skip percentage instructions. Directives like "reduce weight by 50%" are interpreted conservatively as a single DEEMPHASIZE step. Use discrete directives — they're more reliable.
Keep context focused. A handful of targeted directives outperforms long prose paragraphs.

⚠️ What `context` can and can't do

✅ `context` can change	❌ `context` cannot change
Weights of any of the 20 metrics in `overall_match`	Arithmetic metrics like `stability_score` or `location_preference_match` (scores are computed from dates/geography)
Credit for role-family-standard skills and certifications	The JSON schema or the number of metrics
Scoring emphasis across individual dimensions	Personal-data protection rules (resume anonymisation is non-negotiable)

Note on arithmetic metrics: context still adjusts their weight in overall_match — it just doesn't rewrite the individual score itself. If a candidate has a 1-year average tenure, stability_score reflects that fact regardless of directives, but you can make it count for more or less in the overall outcome.

A full request example

POST /api/v1/hr/resume_job_match_score
Content-Type: multipart/form-data
Authorization: Bearer <YOUR_API_KEY>

file:     <resume.pdf>
content:  "Junior Finance Associate — entry-level role.
           Required: Excel, Python, financial modelling, analytics."
language: English
context:  "EMPHASIZE: skills. EMPHASIZE: education.
           DEEMPHASIZE: experience. CREDIT: Excel and Analytics certificates."

The response structure is unchanged — you still get the 20 scored metrics plus explanations for the most important ones — but the numbers will now reflect the directive-adjusted weights.

A word on non-determinism

The context parameter is our primary lever for steering the engine, and we tune it continuously based on the real-world cases our customers bring us. If you hit a scenario where the output doesn't match your expectations, send us the exact request/response — that's the single most valuable feedback we can get.

Get started

Ready to try it? Here's your shortlist:

Read the product details: Resume/CV & Job Description Compatibility Scoring
See it live: CVMatchScore.com — a fully working product built on this exact endpoint
Grab an API key from your SharpAPI dashboard and send your first request
Tell us what's missing — every directive pattern we've shipped started as customer feedback

Happy matching. 🎯

👉 Try the Resume/CV & Job Description Compatibility Scoring API today:
sharpapi.com/en/catalog/ai/hr-tech/resume-cv-job-match-score

Resume Stock photos by Vecteezy

Your AI API, your rules: Introducing Custom AI Job instructions

Dawid Makowski — Thu, 02 Apr 2026 13:26:10 +0000

The problem with one-size-fits-all AI

SharpAPI's endpoints are built to work out of the box. You send a resume, you get a score. You send a job title, you get a description. That's the promise, and it holds for most use cases.

The workaround until now was wrapping our API in your own middleware, manually injecting context before every call. That works, but it's boilerplate you shouldn't have to write.

We shipped a native per-account, per-endpoint instruction system. You write the context once. We inject it into every relevant AI request automatically, at the right layer, without touching your API calls.

How it works

Every SharpAPI account now has a Customize AI Jobs section in the dashboard. It lists all available AI job types grouped by category, from HR and recruitment endpoints to e-commerce and content tools.

For each job type, you can write a free-form instruction. Think of it as a persistent system note to the underlying model: "for every resume scoring request I make, apply these priorities." Once saved and toggled active, that instruction is automatically injected before the AI processes your request.

Step 1: Open the dashboard and go to Customize AI Jobs Find it in the sidebar, right below Custom Workflows. All job types are listed and grouped by category.

Step 2: Expand the endpoint you want to customize Each card has an inline editor. Write your instruction in plain language, no special syntax required.

Step 3: Save and activate You'll see a confirmation prompt before saving, since changing instructions affects your output. Toggle it on, and you're done.

Step 4: Your API calls stay exactly the same No changes to request format, headers, or parameters. The customization happens server-side, invisibly, for every matching request.

What this looks like in practice

Say you're using the Resume Scoring endpoint to screen candidates for a Cloud Architect role. Without a custom prompt, the model scores resumes against a generic template. With one, you can shift those priorities permanently for your account:

Weight cloud certifications (AWS, GCP, Azure) significantly higher than general programming experience. Penalize resumes with no evidence of distributed systems work. Flag any candidate with fewer than 3 years of hands-on infrastructure experience regardless of their total years in software.

Your API call stays unchanged. But behind the scenes, your custom instruction is already baked in. Every candidate's resume is scored against your actual hiring criteria, not a generic baseline.

What you can customize

Tone and style Lock content generation to your brand voice. Formal, conversational, regional, industry-specific -- it's up to you.

Scoring weights Boost or suppress specific signals in scoring endpoints. Relevant for resume scoring, content quality checks, and more.

Output structure Tell the model to always include or exclude certain fields, use specific phrasing, or follow your internal format.

Domain context Give the model background it otherwise wouldn't have: your industry, your audience, your product category.

Note on Custom Workflows: Custom Workflows already support user-defined prompts as a first-class feature. Custom Job Prompts do not apply to Workflow requests -- they're scoped to predefined endpoints only.

Managing your prompts

Action	What it does
Save a prompt	Stores the instruction and activates it immediately
Toggle off	Disables the prompt without deleting it. Default AI behavior restored.
Toggle on	Re-activates a previously saved prompt
Delete	Removes the prompt entirely. Endpoint returns to default behavior.

Every save triggers a confirmation dialog. This is intentional: custom prompts can meaningfully change your outputs, and we want the decision to feel deliberate rather than accidental.

Heads up: Custom prompts are powerful, but they can also produce unexpected results if they conflict with the underlying endpoint logic. If your results start looking off, toggling the prompt off is the fastest way to confirm whether it's the source of the issue.

What this means for teams and integrators

If you're building a product on top of SharpAPI and serving multiple clients, custom prompts let you pre-configure the AI layer for each account without maintaining separate middleware or prompt injection logic on your end. Each account operates independently: one customer's scoring weights don't bleed into another's.

For solo developers, this is simply a way to stop re-writing the same context in every API wrapper you build. Write it once, use it forever, change it whenever your needs shift.

Get started

Custom Job Prompts are available to all accounts with API access. No plan upgrade required. Log into your dashboard, find Customize AI Jobs in the sidebar, and start tuning.

Open Dashboard

The Cloud Is Just Someone Else's Computer. Sometimes That Computer Gets Hit by a Drone.

Dawid Makowski — Tue, 31 Mar 2026 08:58:36 +0000

When "Multi-Region Strategy" Means "Outrunning a Military Conflict"

So last week a military drone blew up the AWS data center where my customer's platform runs. The platform serves millions of users across seven countries. I had to spend about a week moving everything from Bahrain to Europe. By hand. Because every single automated migration tool was also broken. Because, you know, the drones.

I run a software consultancy. I've been in tech long enough to have planned for almost every disaster imaginable. Floods, earthquakes, ransomware, that one guy who drops the production database on a Friday afternoon. "Military drone strike on your cloud provider" was never on the list.

And Bahrain is not an isolated case. Right now, data centers in more than ten countries are being targeted or threatened by either Iranian or russian drones. This isn't a regional incident. It's a global pattern.

And yet, here we are. Welcome to DevOps in 2026.

Disaster Recovery Used to Mean Hurricanes. Now It Means Drones.

If you've worked in infrastructure long enough, you've imagined the disaster scenarios. An earthquake takes out a data center in Tokyo. Hurricane floods a facility in Virginia. Maybe a biblical-scale power outage somewhere in Texas (actually, that one happens pretty regularly). You build for resilience, you plan your failovers, you sleep slightly less terribly at night.

And I don't say "earthquake" lightly. Exactly a year ago, my wife and I were on the top floor of our skyscraper condo in Bangkok when a 7.7 magnitude earthquake hit. One second I was pushing a commit. The next second I was crawling on the floor. The building was swaying two meters each side, and water from the rooftop pool came crashing through into our living room. I still get flashbacks from that. So yes, I understand natural disasters on a very personal, visceral level. I expected those to be the thing that would eventually force me to move servers under pressure.

What I never rehearsed was: "Your entire AWS region is down because a military drone hit all availability zones in Bahrain."

Yet here we are.

In early March, Iranian drones struck multiple AWS facilities across the UAE and Bahrain. This wasn't some theoretical threat model from a security conference whiteboard. This was the first confirmed military attack on a major hyperscale cloud provider's infrastructure. Banking apps went down. Payment systems collapsed. Delivery platforms across the Gulf went dark. And somewhere in Thailand, my phone started buzzing with messages from a very worried customer in Saudi Arabia.

There's No Terraform Module for Surviving a War Zone

Here's what you need to understand about the week that followed: every single automated migration tool AWS provides was broken. CloudWatch, the thing that tells you if your servers are even alive? Gone. RDS Snapshots, the thing you use to back up databases before you touch anything? Unavailable. Cross-region transfer? Dead. AMI copies? Nope.

It was like showing up to a house fire and discovering that not only is your fire truck empty, but someone also stole the hydrant.

So I did what any reasonable engineer would do. I had to rebuilt multiple production environments from scratch, on bare Linux images, in Europe. By hand. For a platform serving millions of users across seven countries. I wrote custom scripts to export, compress, and transfer everything over the public internet (because AWS's own internal backbone between regions was also down). I wrote manual rescue scripts for files that kept failing for days with InternalError. I worked nights because often it was the only window where platform traffic was low enough to safely verify everything.

One week of controlled chaos. And by the end of it, the entire platform was running smoothly from Europe, as if nothing had happened.

But everything had happened.

We're a Software Company. Why Do We Keep Running From Wars?

I could tell this story as a purely technical narrative. Here's the architecture, here's the migration plan, here's the clever script that saved the day. But that would miss the point entirely.

Because here's what my day-to-day actually looks like:

I run a small tech consultancy. We build custom software. We manage cloud infrastructure. We automate businesses with AI workflows. Very normal stuff. And yet somehow, every single person on my team has been touched by war. Not metaphorically. Literally.

I live in Thailand, which recently had skirmishes with Cambodia along the border. My Iranian engineer had to flee Iran with his entire family. One of my coworkers lives in Ukraine, literally in a war zone, delivering code between power cuts because the grid keeps getting hit by Iranian-designed drones. A couple of months ago he went to an immigration office across the border and couldn't come back for days because russians bombed the only bridge on his route home. Another colleague had to evacuate Ukraine with his whole family.

We write code and configure servers. We're not defense contractors. We're not geopolitical analysts. We're developers who just want to ship clean code and go home.

And yet, every week, somewhere on this planet, a conflict reaches through the internet cables and grabs us by the collar.

The Strangest Plot Twist of 2026

And now, in what might be the most unexpected geopolitical crossover episode of the decade: Ukraine is protecting Saudi skies.

Let that sink in for a second. The country that has been fighting for its own survival since 2022, that has become the world's foremost expert on shooting down drones because it had no choice, has just signed defense cooperation agreements with Saudi Arabia, Qatar, and the UAE. Over 200 Ukrainian drone-countering specialists are now deployed across the Gulf, helping defend the very region where my customer's servers used to live.

The same drones that forced me to migrate infrastructure out of Bahrain? Ukraine knows those drones intimately. They've been dealing with their Iranian-made cousins, the Shaheds, for years.

So now the country of my colleague who codes between blackouts is also the country protecting the airspace above my customer's business. If you wrote this as fiction, your editor would tell you it's too on the nose.

Who Else Is Living This?

I can't be the only one. There must be thousands of engineers, sysadmins, CTOs, and DevOps folks out there who have spent the last few years making decisions that no technical manual covers. Moving workloads because of missiles. Rerouting traffic because of sanctions. Keeping systems alive through infrastructure that's being actively targeted.

If you've had to migrate production systems because of armed conflict, I'd love to hear your story.

The New Normal (Which Is Not Normal At All)

Twenty years ago, your biggest infrastructure worry was a hard drive failing or router dropping packets. Ten years ago, it was maybe a ransomware attack. Today, it's a state-sponsored drone strike on your cloud provider's physical data center.

We've entered an era where "disaster recovery" needs to account for actual disasters of the military kind. Where your multi-region strategy isn't just about latency and compliance, it's about geopolitical risk assessment.

The conflicts we see on the news aren't happening "over there" anymore. They're happening inside our dashboards, our uptime monitors, our incident channels. Every single one of us in tech is connected to these events whether we like it or not.

The world got very small, and very complicated, very fast.

Check more at my blog.

Introducing Custom Workflows: Turn Any AI Prompt Into a Production API

Dawid Makowski — Mon, 16 Mar 2026 16:28:07 +0000

Photo by Campaign Creators on Unsplash

Building AI-powered features into your product usually means weeks of backend development, prompt engineering, infrastructure setup, and deployment headaches. What if you could skip all of that and go from an idea to a live REST API endpoint in under 60 seconds?

That is exactly what Custom Workflows delivers. A visual builder in the SharpAPI Dashboard lets you define typed input parameters, write your processing logic as a plain-English prompt, and generate a production-ready API endpoint on the spot. The result is a fully authenticated REST API that accepts your inputs, runs them through the AI model of your choice, and returns structured JSON matching the output schema you defined. No backend code. No deployment pipeline. No infrastructure to manage. Just your idea, instantly available as an endpoint.

The Problem: AI Integration Is Still Too Hard

Every development team has a backlog of AI features they want to build. Extract data from invoices. Classify support tickets. Generate product descriptions. Score leads. Moderate content.

Each of these features follows the same pattern: take some input, send it to an AI model, parse the response, and return structured data. And yet, building each one from scratch means writing boilerplate code, handling API communication with model providers, parsing unpredictable outputs into reliable schemas, setting up async processing for long-running tasks, and deploying the whole thing somewhere.

Custom Workflows eliminates every one of those steps.

How It Works: A 5-Step Visual Builder

The Custom Workflows builder lives right in the SharpAPI Dashboard. It walks you through five straightforward steps:

Step 1: Basic Info. Give your workflow a name and description, then choose your input mode (JSON for structured data or Form-Data for file uploads).

Step 2: Parameters. Define your input parameters with types, labels, default values, and required/optional flags. The system supports the full range of types you would expect: strings, numbers, booleans, arrays, and objects for JSON mode, plus text and file inputs for Form-Data mode.

Step 3: AI Prompt. Write what you want the AI to do, in plain English. No prompt engineering expertise needed. If you are not sure where to start, pick one of the pre-made templates (more on those below) and customize it.

Step 4: Output Schema. Define the JSON structure you want back. Or just click one button and let the AI analyze your workflow context to suggest an optimal schema automatically.

Step 5: Review & Save. Preview everything, activate, and grab your endpoint URL. You are live.

That is the whole process. Five steps, and you have a production API.

What You Get: A Real API, Not a Toy

Every saved workflow immediately becomes a live REST endpoint:

POST /api/v1/custom/{your-workflow-slug}

It uses the same API key authentication (X-API-KEY header) as every other SharpAPI endpoint. No additional setup or configuration.

Processing follows the standard SharpAPI async pattern for reliability at scale. You send a POST request and get back a 202 Accepted with a status_url and job_id. Poll the status URL until the job completes, then retrieve your structured JSON result matching the exact output schema you defined.

Every workflow also exposes a self-describing GET endpoint that returns its complete specification: parameter definitions, types, labels, required flags, defaults, output schema, and endpoint URL. This is perfect for auto-generating client code or feeding into other AI systems that need to understand what your API does.

Type Safety Without the Boilerplate

The parameter system is strict by design. Every input parameter is validated against its declared type before any processing begins. Required parameters must be present. Default values fill in for optional ones. And in JSON mode, unknown parameters are automatically rejected, preventing typos and unexpected inputs from sneaking through.

This gives you the kind of type safety you would normally need backend code to enforce, except you get it for free.

Real-World Use Cases

Here is where it gets practical. Custom Workflows can power a wide range of features across industries:

Document Processing. Upload invoices, contracts, receipts, or forms and extract structured data at scale. Pair Form-Data input mode with a file parameter and you have a document processing API in minutes. Think insurance claim forms, medical records intake, shipping manifests, purchase orders, or tax documents.

Content Analysis. Sentiment analysis, content moderation, tone detection, urgency classification. Feed text in, get structured scores and labels out. Great for analyzing customer reviews, social media mentions, support tickets, survey responses, app store feedback, and forum posts.

Content Generation. Automated email drafts, product descriptions, social media posts, marketing copy. Consistent, on-brand content delivered via API. Use it for personalized outreach emails, SEO meta descriptions, product listing copy for e-commerce catalogs, newsletter sections, ad variations, or localized marketing content.

Data Enrichment. Add AI-powered insights, classifications, and predictions to your existing data pipelines. Plug a Custom Workflow into your ETL process and enrich records as they flow through. Classify CRM leads by intent, tag support conversations by topic, extract skills from resumes, or categorize transactions by spend type.

Risk Assessment. Compliance checking, fraud detection signals, policy violation screening. Get structured risk scores through a simple API call. Screen user-generated content for policy violations, flag suspicious transaction patterns, evaluate vendor contracts for non-standard clauses, or check marketing copy against regulatory guidelines.

Customer Support Automation. Route incoming tickets to the right team, suggest reply templates, extract key details (order numbers, product names, issue categories) from customer messages, or generate first-draft responses for agents to review.

E-commerce & Product. Automate product categorization and tagging, generate comparison tables, extract specs from manufacturer datasheets, translate listings for international storefronts, or normalize product attributes across multiple suppliers.

HR & Recruitment. Parse resumes and extract structured candidate profiles, screen cover letters, generate interview question sets tailored to job descriptions, summarize employee feedback surveys, or classify internal knowledge base articles.

Legal & Finance. Summarize contract clauses, extract key terms and obligations, flag non-standard language in agreements, categorize expense reports, or generate structured abstracts from regulatory filings.

Education & Research. Summarize academic papers, extract citations and key findings, generate quiz questions from study materials, classify research topics, or transform lecture notes into structured outlines.

SDKs for Every Stack

Official SDKs are available for PHP, Laravel, Python, and JavaScript/TypeScript. Browse all Custom Workflow SDK packages on GitHub.

Pricing: No Surprises

Custom Workflows use the same credit-based billing system as every other SharpAPI endpoint. There is no extra charge, no separate pricing tier, no hidden fees. If you have credits, you can run workflows.

The feature is available on all plans, from the free tier up to enterprise. Scale and Enterprise plans include additional support for custom endpoint configuration, dedicated account management, and custom SLAs.

The Numbers

30+ pre-built AI endpoints already available alongside Custom Workflows
Unlimited custom workflows on every plan
99.9% API uptime
SOC 2 Type II certified

Get Started

Custom Workflows is live in the SharpAPI Dashboard right now. Log in, click "Create Workflow," and have your first custom AI endpoint running in under a minute.

Whether you are building a document processing pipeline, adding AI-powered content analysis to your SaaS product, or just prototyping a new feature idea, Custom Workflows gives you the fastest path from concept to production API.

Ready to turn your AI prompts into production endpoints? Head to https://sharpapi.com/custom-workflows and start building.

You Just Gave OpenClaw the Keys to Your Entire Digital Life - on a VPS Server You Don't Know How to Secure

Dawid Makowski — Tue, 24 Feb 2026 15:08:37 +0000

You Put OpenClaw on a VPS. It Has Access to Everything. You Secured None of It. Let's Fix That in 30 Minutes.

This guide was written for the brave souls who saw the OpenClaw hype train, jumped aboard, spun up their first VPS, and then had the terrifying realization that they now need to learn Linux security. You're going to be fine. Probably.

Look, I get it. You saw the hype. You saw the tweets. You saw some guy on Reddit say OpenClaw changed his life, and now you're sitting there at 2 AM with your very first VPS, a fresh install of OpenClaw, and the sudden realization that you just handed an AI assistant the keys to your email, your calendar, your Google Drive, your private documents, and basically your entire digital soul - all running on a server you've never secured before because, well, this is your first server.

Now, let's be fair: a fresh Ubuntu installation isn't actually a house with no doors. Ubuntu ships with sensible defaults - no unnecessary open ports, no sketchy services running, SSH with reasonable settings. Credit where credit is due. But here's the problem: you're not running a fresh Ubuntu installation anymore. You're running OpenClaw on top of it. With plugins. And skills. And extensions. And API keys to everything you own.

Here's a fun fact to help you sleep tonight: every VPS that connects to the internet gets fully port-scanned by automated bots within 10 to 20 minutes. Not hours. Not days. Minutes.

But with OpenClaw and its ecosystem of plugins exposing additional services and APIs? Now you're interesting. And on the internet, you do not want to be interesting.

And look - I'm not here to trash OpenClaw. It's genuinely cool. The AI-assistant-on-your-own-server dream is alive and well. But let's be honest with ourselves for a moment: OpenClaw, plus all of its plugins, skills, and extensions, is not exactly what security researchers would call "airtight." It's more what they'd call "a fun afternoon." The platform is young, moving fast, and the attack surface grows with every skill you install. The real risk isn't Ubuntu's defaults - it's everything you're bolting on top of them.

So since we can't fix OpenClaw's security overnight, let's make damn sure that the server underneath it is locked down tight, so that even if someone finds a vulnerability in a plugin, they hit a brick wall instead of a buffet.

The good news? I recommend Ubuntu for your VPS, and I'm going to walk you through this whole thing step by step.

Why Ubuntu? Because it has a massive community, a mountain of security tools, and - this is the important part - any non-technical noob can harden it in about 30 minutes with proper guidance.

Let's go. And please, for the love of everything, don't close your terminal until I tell you to.

Step 0 - Non-root user

Before we do anything else - if you're still logged in as root like some kind of digital cowboy, we need to fix that immediately. Root is the god account. It can do anything, break anything, and delete anything, including itself.

So let's create a proper user and give it sudo powers:

adduser ubuntu
usermod -aG sudo ubuntu

Now, because typing your password every time you run sudo gets old approximately 4 seconds after the first time, let's set up passwordless sudo. Run visudo and add this line at the very bottom:

ubuntu ALL=(ALL) NOPASSWD:ALL

From this point on, you do everything as ubuntu and use sudo when you need elevated privileges. Think of root as the emergency fire axe behind glass - it's there if you need it, but you shouldn't be casually swinging it around on a Tuesday afternoon.

Now copy your SSH key to the new user (ssh-copy-id or manually paste it into /home/ubuntu/.ssh/authorized_keys), log in as ubuntu in a new terminal to make sure it works, and never log in as root again.

Step 1: Set Your Timezone

Before we do anything dramatic, let's make sure your server knows what time it is. This sounds trivial, but accurate timestamps in your logs are the difference between "I can see exactly when someone broke in" and "something happened... at some point...

dpkg-reconfigure tzdata

Pick your timezone from the menu. It's interactive.

Step 2: Update Everything

Your server shipped with software that was already outdated by the time you clicked "Deploy." Let's fix that.

apt update && apt upgrade -y

This updates all your packages to their latest versions, patching known vulnerabilities. Think of it as putting on pants before leaving the house. Bare minimum.

Now, because we both know you're going to forget to do this regularly (I know you, and I love you, but I know you), let's set up automatic security updates:

apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

This configures your server to automatically install critical security patches without you having to remember. It's like hiring a tiny robot butler whose only job is to lock the doors you keep leaving open.

Step 3: Set Up Ubuntu Pro

Ubuntu Pro gives you expanded security maintenance, kernel live patching, and compliance tools. And here's the kicker - it's free for up to 5 machines.

Go to ubuntu.com/pro, grab your token, and attach it:

pro attach YOUR_TOKEN_HERE

This extends your security coverage and covers thousands of additional packages. It's like getting the extended warranty, except it actually does something.

Step 4: Lock Down SSH

SSH is how you talk to your server. It's also how everyone else tries to talk to your server. By default, it's running on port 22, which is the first port every bot on the internet checks. That's like hiding your house key under the doormat - the one place literally everyone looks first.

Edit your SSH config:

nano /etc/ssh/sshd_config

Here's what your config should look like. I'll explain each line, because I respect you and your journey:

Port 55222                            # Move SSH off the default port. Not foolproof, but stops 90% of really lazy scanners.
LoginGraceTime 2m                     # You get 2 minutes to authenticate. After that, goodbye.
PermitRootLogin no                    # NOBODY logs in as root. Ever. Not even you. Especially you.
MaxAuthTries 5                        # 5 wrong passwords and we hang up on you. Rude? Maybe. Secure? Yes.
PasswordAuthentication no             # No passwords. Period. Keys only. Passwords are the cargo shorts of security.
PermitEmptyPasswords no               # Just... no. Come on.
AllowUsers ubuntu                     # Only the 'ubuntu' user can log in. Everyone else can go home.
X11Forwarding no                      # No graphical forwarding. This is a server, not a gaming PC.
PermitUserEnvironment no              # Don't let users set environment variables through SSH. Trust issues? You bet.
AllowAgentForwarding no               # No SSH agent forwarding. Reduces the risk of key theft.
AllowTcpForwarding no                 # No TCP tunneling through your server. It's not a VPN.
PermitTunnel no                       # Same energy as above. No tunnels.
KbdInteractiveAuthentication yes      # Needed for 2FA (we'll get there, be patient).
ChallengeResponseAuthentication yes   # Also needed for 2FA. The dynamic duo.
AuthenticationMethods publickey,keyboard-interactive  # Key first, then 2FA code. Belt AND suspenders.
UsePAM yes                            # Use PAM for authentication. Required for Google Authenticator.

The key takeaways: We moved the SSH port (so bots can't find it easily), disabled root login (so even if someone gets in, they're not god), killed password authentication (keys only, like a VIP club), and set up the groundwork for two-factor authentication.

Now reload SSH so it actually pays attention to what we just told it:

sshd -t && systemctl reload ssh.service

The sshd -t part tests your config first. If there's a typo, it'll tell you before you lock yourself out. Because locking yourself out of your own server is a very special kind of pain.

⚠️ CRITICAL: Do NOT close your current terminal session yet. Open a NEW terminal and test that you can still connect with your new settings before closing anything.

ssh -i /path/to/your-key -p 55222 ubuntu@your-server-ip

Step 5: Install Fail2Ban

Fail2Ban watches your authentication logs and automatically bans IP addresses that fail to log in too many times. It's basically a nightclub bouncer for your server.

apt install fail2ban -y

Out of the box, Fail2Ban will monitor SSH and ban anyone who fails authentication repeatedly. You can customize the jail settings later, but the defaults are already pretty solid for keeping the riff-raff out.

Think of it this way: Step 4 made it harder to get in. Step 5 makes sure that anyone who keeps trying gets permanently shown the door.

Step 6: Set Up Two-Factor Authentication

This is the big one. This is where we go from "pretty secure" to "okay, now I can actually sleep at night."

Two-factor authentication means that even if someone somehow gets your SSH key (it happens - laptops get stolen, backups get leaked, your cat walks across your keyboard and emails it to someone), they STILL can't get in without the 6-digit code from your phone.

Install Google Authenticator:

apt install libpam-google-authenticator -y

Switch to your ubuntu user and run the setup:

su - ubuntu
google-authenticator

It'll ask you some questions. Here are the correct answers (you're welcome):

Prompt	Answer	Why
Time-based tokens?	y	Time-based is more secure than counter-based
Update .google_authenticator file?	y	This saves your config
Disallow multiple uses?	y	Each code works exactly once
Increase time window?	n	Keep it tight
Rate limiting?	y	Slows down brute-force attempts

It'll show you a QR code. Scan it with Google Authenticator, Authy, or whatever TOTP app you prefer. And for the love of all that is holy, SAVE THE EMERGENCY SCRATCH CODES.

Put them in a password manager (important!). They're your "break glass in case of emergency" codes if you lose your phone.

Configure PAM (this tells SSH to actually use the authenticator):

sudo nano /etc/pam.d/sshd

Add this line at the very top:

auth required pam_google_authenticator.so

And comment out this line (to prevent a double password prompt, which is annoying and unnecessary):

# @include common-auth

Make sure your SSH config has these lines set correctly (most of them should already be right from Step 4):

KbdInteractiveAuthentication yes
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
UsePAM yes
PasswordAuthentication no

Test the config and restart SSH:

sshd -t && systemctl restart ssh

Now test in a NEW terminal (seriously, keep your current session open - are you sensing a pattern here?):

ssh -i /path/to/your-key -p 55222 ubuntu@your-server-ip

Your login flow should now be: SSH key → TOTP verification code → you're in. No password involved. Just your key and your phone. It's like a secret handshake, but actually secure.

Step 7: Monitor Your Logs

Congratulations, your server is now significantly more secure than it was 20 minutes ago. But you need to actually check on things occasionally.

Check your SSH authentication logs:

sudo cat /var/log/auth.log | grep sshd

For live monitoring (great for watching scans/attacks happen in real-time, which is weirdly entertaining):

sudo tail -f /var/log/auth.log

What to look for:

Repeated failed login attempts - Fail2Ban should catch these, but check anyway
Login attempts from unfamiliar IP addresses - If you see IPs you don't recognize, investigate
Unknown usernames - If someone's trying to log in as "admin" or "test," that's a bot
Successful logins at weird hours - If you logged in at 3 AM and you were asleep at 3 AM, we have a problem

Bonus Round: For the Ambitious

If you've made it this far and you're feeling confident (possibly too confident, but I respect the energy), here are two next-level options:

Tailscale

Tailscale creates a private mesh VPN between your devices. Once set up, you can access your server through a private network that isn't exposed to the public internet at all. It's like having a secret tunnel to your server that only you know about. The setup is shockingly simple for something this powerful.

Cloudflare Tunnel

Cloudflare Tunnel lets you expose your OpenClaw instance to the internet without opening ANY inbound ports on your server. Zero. None. The server reaches out to Cloudflare, and Cloudflare handles all incoming traffic. It's like having a P.O. Box for your server - people can send you mail, but they don't know where you live.

Both of these are excellent options if you want to take your security from "solid" to "paranoid, but like, in a healthy way."

Final Thoughts

If you're running OpenClaw on a VPS, you've put your most private digital life on a server connected to the open internet. Your emails. Your calendar. Your documents. Your credentials. All of it sitting there, protected by whatever security you bothered to set up.

Is your server now impenetrable? No. Nothing is impenetrable. But you've gone from being a soft, delicious target to being the server that's maybe not worth the effort today when there are millions of easier ones to hit.

You've got this. Probably. I believe in you. Mostly.

How We Automated Invoice Processing for Our Clients

Dawid Makowski — Mon, 23 Feb 2026 15:11:05 +0000

If you've ever watched a finance team manually key in invoice data from a stack of PDFs, phone photos, and scanned documents, you know the look. It's somewhere between existential dread and quiet resignation. We've seen it across multiple client engagements - fintech, retail, logistics - and the story is always the same. Smart people doing dumb work because the tools they have can't handle the chaos of real invoices.

So we fixed it.

The Problem We Kept Running Into

Across our client projects, invoice processing kept showing up as a bottleneck. Not because the concept is hard, but because the reality is messy. Invoices arrive as pristine PDFs sometimes, sure. But more often they show up as phone photos taken at weird angles with bad lighting, scanned TIFFs from office equipment that should have been retired a decade ago, or flattened PDFs where the text is baked into images and not selectable.

Every off-the-shelf OCR solution we tried would work great on the clean files and fall apart on everything else. And "everything else" is most of what shows up in production.

What We Built

We designed a multi-step AI pipeline that approaches invoice parsing the way a human would -- if that human could process thousands of documents per hour without making mistakes.

Step 1: ML-powered OCR extracts the raw content from the file, regardless of format or quality. This isn't your basic Tesseract setup. It's trained to handle the messy stuff -- crumpled paper, shadows, skewed scans, multi-page documents.

Step 2: AI processing rounds take that raw extraction and run it through multiple validation and structuring passes. This is where the magic happens. The AI identifies what's a line item vs. a header vs. a tax calculation, maps seller and buyer information correctly, and resolves ambiguities that would trip up simpler systems.

The result is a clean, structured JSON object with 100+ data fields covering everything you'd ever need from an invoice: document metadata, seller/buyer details with full addresses, financial breakdowns with tax calculations, individual line items, payment terms, logistics info, e-invoice metadata, and reference numbers.

What It Handles

We built this for the real world, not demo day. That means it works with:

8 file formats: PDF, DOC, DOCX, JPG, JPEG, PNG, TIFF, TIF
Messy phone photos: crumpled paper, bad lighting, weird angles -- the kind of stuff your field teams actually send in
Scanned invoices and flattened PDFs: where the content is images, not selectable text
Multi-page invoices: processes the full document, not just the first page
Multi-currency invoices: extracts currency info, exchange rates, VAT/GST/SST IDs, and country-specific tax details
80+ languages: from English to Japanese to Arabic

How Our Clients Use It

Once we had this working, the use cases multiplied fast:

Accounts payable automation - the obvious one. Invoices come in, structured data comes out, AP workflow picks it up. Processing time goes from minutes per invoice to seconds.

ERP and accounting integration - clean, consistent data piped straight into QuickBooks, Xero, SAP, NetSuite, or whatever the client is running. No more "which field maps to what" conversations with the finance team.

Spend analytics - when every invoice is structured data, building dashboards and running analyses across your entire vendor base becomes trivial. Clients use this to spot trends, negotiate better terms, and flag cost-saving opportunities.

Fraud detection - cross-referencing parsed invoice data against purchase orders and contracts to automatically flag discrepancies before payments go out.

Expense management and compliance - automating expense report validation against company policies and maintaining audit trails without human intervention.

We Made It Available to Everyone

Rather than keep this locked inside client projects, we productized the entire pipeline as part of SharpAPI -- our AI workflow automation API. The Invoice Parsing endpoint is live and available on all plans.

Integration follows the same simple async pattern as all SharpAPI endpoints:

curl --location 'https://sharpapi.com/api/v1/invoice/parse' \
--header 'Accept: application/json' \
-H "Authorization: Bearer YOUR_API_TOKEN" \
--form 'file=@"invoice.pdf"'

POST your file, get a job ID, poll for results. That's it.

And because we know developers hate writing boilerplate HTTP code, there are ready-to-go SDK packages for PHP, Laravel, Node.js, Python, and .NET on GitHub:

Browse Invoice Parsing SDKs on GitHub

Why This Matters for Your Business

Manual invoice processing costs businesses an average of $15-$40 per invoice when you factor in labor, errors, and delays. At scale, that adds up fast. If your team processes a few hundred invoices a month, you're looking at significant savings just by automating the extraction step -- not to mention the reduction in errors that cause payment disputes, compliance issues, and vendor relationship headaches.

We built this because we kept seeing the same problem across different industries and different clients. If your business deals with invoices at any meaningful volume, this is the kind of automation that pays for itself in the first week.

Get Started

Product page: SharpAPI Invoice Parser
Detailed blog post with full response examples: Invoice Parsing API - Extract Structured Data from Any Invoice

Everything runs on SOC 2 Type II certified infrastructure, so your invoice data is handled with the same security standards we maintain across all our client work.

Got a specific invoice processing challenge? Talk to us - whether you need the API integrated into your existing systems or a full custom workflow built around it, that's literally what we do.

Invoice Parsing API - Extract Structured Data from Any Invoice

Dawid Makowski — Sun, 22 Feb 2026 08:41:16 +0000

Photo by Cht Gsml on Unsplash

What It Does

Upload an invoice in any of 8 supported formats (DOC, DOCX, PDF, JPG, JPEG, PNG, TIFF, TIF), and the API extracts and structures the entire document into a comprehensive data object. We're talking seller and buyer details, full financial breakdowns with tax calculations, individual line items, payment terms, logistics info, e-invoice metadata, and reference numbers — all neatly organized and ready for your systems.

And yes, it handles scanned invoices and flattened PDFs where the content is images rather than selectable text. Because in the real world, invoices aren't always pixel-perfect.

Real-World Use Cases

Automated Accounts Payable

Feed invoices directly into your AP workflow. The API extracts vendor details, amounts, due dates, and line items — eliminating manual data entry and reducing processing time from minutes per invoice to seconds.

ERP & Accounting System Integration

Pipe structured invoice data straight into your ERP (SAP, Oracle, NetSuite, QuickBooks, Xero — you name it). No more reconciliation headaches, no more "which field maps to what" conversations. The data comes out clean and consistent every time.

Spend Analytics & Vendor Management

Aggregate invoice data across your entire vendor base to spot spending trends, negotiate better terms, and identify cost-saving opportunities. When every invoice is structured data, building dashboards and running analyses becomes trivial.

Expense Management & Compliance

Automate expense report validation by parsing receipts and invoices. Cross-reference extracted data against company policies, flag anomalies, and maintain a clean audit trail — all without human intervention.

Multi-Currency & Cross-Border Operations

The API extracts currency information, exchange rates, VAT/GST/SST IDs, and country-specific tax details. Perfect for businesses operating across borders that need to handle invoices in multiple currencies and comply with regional tax requirements.

Invoice Verification & Fraud Detection

Compare extracted invoice data against purchase orders, delivery receipts, and contracts. Automatically flag discrepancies in quantities, pricing, or vendor information before payments go out.

How It Works

Like all SharpAPI endpoints, Invoice Parsing follows a simple two-step async pattern:

Step 1: Submit your invoice file via a POST request to https://sharpapi.com/api/v1/finance/parse_invoice. You'll receive a job ID and status URL.

Step 2: Poll the status URL until the job completes. The result contains the full structured invoice data.

curl --location 'https://sharpapi.com/api/v1/finance/parse_invoice' \
--header 'Accept: application/json' \
-H "Authorization: Bearer YOUR_API_TOKEN" \
--form 'file=@"invoice.pdf"'

The response includes over 100 individual data fields organized into logical sections: document metadata, invoice details, references, e-invoice data, seller/buyer information, financials with tax breakdowns, line items, payment terms, and logistics data.

Why This Matters

Manual invoice processing costs businesses an average of $15–$40 per invoice when you factor in labor, errors, and delays. At scale, that adds up fast. By automating the extraction step, you're not just saving time — you're eliminating the single biggest source of AP errors and freeing your team to focus on work that actually requires human judgment.

Get Started

The Invoice Parsing endpoint is available now on all SharpAPI plans. Check out the details of Invoice Parsing for detailed request/response schemas, supported languages, and integration guides.

Your invoices aren't going to parse themselves. Well, actually — now they will.

Integrate faster with SharpAPI SDKs.
Ready-to-use client packages for PHP, Laravel, Node.js, Python, Flutter, and .NET are available on GitHub.
Browse Invoice Parsing SDKs →

Your Penetration Test Report Just Landed. Read This Before You Panic.

Dawid Makowski — Tue, 17 Feb 2026 10:29:04 +0000

I've watched the same movie play out too many times: a management team receives a penetration testing report, sees a wall of findings with scary-sounding names, and immediately assumes their platform is on fire.

It's not on fire. It's almost never on fire.

But the report sure makes it look like it is. And that's the problem I keep running into - not with the platforms, but with how people read these reports.

The Translation Problem

When you're a CTO or an external CTO-as-a-Service advisor, part of the job is translating between the world of security tooling and the world of business decision-making. These two worlds speak very different languages. Security tools speak in volumes of automated findings. Business leaders speak in risk, cost, and "should I be worried right now?"

That gap is where the panic starts.

Over the years I've learned to get ahead of it. Before every VAPT (Vulnerability Assessment and Penetration Testing) cycle, I walk my clients through what to expect from the results - what the findings actually mean, what's noise, and what deserves real attention. It's part education, part expectation management, and part gentle reminder that a 200-page PDF full of findings does not mean the sky is falling. Sometimes it just means the scanner was very thorough and a bit too enthusiastic.

The goal is simple: give non-technical stakeholders the mental framework to read a VAPT report without losing sleep. Because the report is only half of the story. The other half - the part that actually matters - is interpreting those findings in the context of your platform, your architecture, and your specific business requirements.

The Anatomy of a VAPT Report (For Humans)

Here's what most people don't realize about penetration testing: the raw output of any engagement is never the final verdict on your security. It's a starting point for analysis.

VAPT teams rely on automated scanning tools to generate their initial findings. These tools are designed to cast an absurdly wide net. They flag anything that could theoretically be a concern. And I mean anything. Your OAuth integration with Google? Flagged. Your CDN serving static assets from a different domain? Flagged. A cookie that JavaScript can access because your entire framework was literally designed that way? You better believe that's flagged. Any open port on the server, even port 80 or 443? Yup, also flagged.

This isn't a flaw in the process. It's how the process works. The tools are doing their job. The question is what happens next.

The Quality Gap Nobody Talks About

And here's where it gets interesting.

Not all VAPT teams are created equal. In fact, there's a pretty dramatic quality spectrum, and where your team falls on it determines whether you receive a useful, contextualised security assessment or a PDF-shaped anxiety attack.

Budget-oriented teams tend to optimise for volume. They run the tools, collect the output, and forward everything to the client with minimal filtering. The result? A report with dozens - sometimes hundreds - of findings, many of which are informational noise or outright false positives. It looks impressive. It fills a lot of pages. But it creates exactly the kind of alarm that derails productive conversations about actual security.

I've seen reports where the same exact finding was listed separately for every URL on the platform. Same issue, same root cause, same "vulnerability" - just presented 147 times to make the PDF thicker.

More experienced teams - and yes, they typically cost more - invest significant effort in triaging their tool output before presenting it. They separate signal from noise. They tell you what actually matters and why. They cross-reference previous engagement results instead of re-investigating known behaviours from scratch. Their reports are shorter, more accurate, and infinitely more useful. You're paying for judgment, not just scanning hours.

Severity Levels: A Quick Decoder Ring

Every VAPT report categorises findings by severity. Here's the practical translation:

Critical and High - Stop what you're doing and fix these. These represent real, exploitable vulnerabilities. In a well-maintained platform with regular dependency updates, strong authentication, and proper encryption, these should be rare. If your report is full of them, you have a genuine problem. If it has zero, congratulations - that's the goal.

Medium and Low - Read these with a calm mind. They often represent theoretical risks, hardening suggestions, or configuration preferences. Many are informational. Think of them as a security consultant saying "you could also do this" rather than "your house is currently on fire."

Informational - These are diagnostic notes. They describe how your platform behaves. They don't indicate risk. You can acknowledge them and move on.

The number of findings in a report tells you almost nothing about how secure your platform is. A report with 150 findings and zero criticals is a dramatically better result than one with 5 findings and 2 criticals.

False Positives: The Uninvited Guests

Every - and I mean every - VAPT engagement produces false positives. These are findings that automated tools flag as potential issues but which, upon analysis, turn out to be expected framework behaviours, design decisions, or artefacts of the cloud infrastructure itself.

In a recent engagement, we documented over 20 false positives across two reports. The cloud provider's own security infrastructure was triggering alerts during the scan - the scanning tools were essentially detecting the host's defence systems and reporting them as application vulnerabilities. That's like a home inspector flagging your alarm system as a security risk. Technically, something happened. Practically, it's the opposite of a problem.

Context Is Everything

If there's one thing I want people to take away from this, it's this: a VAPT report must always be read in the context of the specific platform it was conducted against.

Security is not a one-size-fits-all discipline. A finding that represents a genuine vulnerability on one platform could be an intentional design decision on another. Session tokens in URLs? Alarming - unless they're part of a standard OAuth handshake with a provider like Google or Twitter, in which case they're temporary, scoped, and exactly where they're supposed to be. Cross-domain script includes? Suspicious - unless they're loading Google's reCAPTCHA or your SSO integration, in which case they're essential.

The report is half of the truth. The contextual analysis is the other half. Without both, you're making decisions based on incomplete information - and in my experience, those decisions tend to lean toward unnecessary panic and wasted remediation effort.

If you have a VAPT cycle coming up, prepare your stakeholders before the report lands. It'll save you a week of damage-control conversations that didn't need to happen.

CVMatchScore.com: A Real-World Showcase of Our Resume Match API

Dawid Makowski — Fri, 09 Jan 2026 12:17:51 +0000

Photo by Nik on Unsplash

We just launched a small thing that accidentally became useful.

It’s called CV Match Score:
https://cvmatchscore.com

The backstory is simple. I kept getting the same question from people building HR tools and workflows:

“Cool endpoint. But what does it actually look like when a real human uses it?”

Fair. JSON is charming, but it doesn’t exactly spark joy.

So we built a tiny, fully functional product that showcases our SharpAPI endpoint in the wild, under real conditions, with real inputs. No screenshots. No “imagine it works like this.” It just works.

Behind the scenes, CV Match Score uses this SharpAPI capability:
https://sharpapi.com/en/catalog/ai/hr-tech/resume-cv-job-match-score

What it does:

You upload a CV.
You paste a job description.
You get a structured match score with explanations that make sense to humans, not just to machines having a meeting about keywords.

Why we built it (beyond our obvious addiction to shipping):

Documentation tells you what an API returns.
A working tool shows you what users feel.
And that’s the difference between “nice endpoint” and “this can be a feature inside my product next week.”

If you’re building:

HR tech products
ATS features
internal screening workflows
recruitment automation

This tool is basically a fast, honest preview of what the endpoint enables when you put a UI in front of it.

Try it, break it, tell us what’s missing!

Fixing Spatie's Laravel ResponseCache to Respect Accept-Language

Dawid Makowski — Thu, 21 Aug 2025 09:18:38 +0000

I’ll be honest. Few things are more frustrating than solving a problem by reaching for a great package… only to realize the problem is still there. That was me last week, yelling at my API like it had just spoiled the finale of a Netflix show.

I was using Spatie’s Laravel ResponseCache package. It’s rock solid, it works out of the box, and it’s built by people I trust. But here’s the kicker: I turned it on in production and suddenly my multilingual API was speaking one language only. The first request cached in English. Every Arabic request after that? Still English.

So here’s what it took to fix it. I hope it will help some lost soul on the internet one day.

Photo by Douglas Lopes on Unsplash

The Problem

Spatie’s ResponseCache builds cache keys from the host, normalized URI, HTTP method, and a suffix (usually the user ID). That works fine most of the time, but it completely ignores request headers like Accept-Language.

Which means:

First request with Accept-Language: en → response cached in English
Second request with Accept-Language: ar → still gets the English version

My API became linguistically challenged.

The Fix: Middleware That Cares About Language

Spatie lets you influence the cache key by setting a per-request attribute called responsecache.cacheNameSuffix. All we have to do is populate it with something that changes when the language changes.

Here’s the middleware I ended up shipping:

<?php

declare(strict_types=1);

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Illuminate\Support\Str;

class SetResponseCacheSuffixFromLanguage
{
    public function handle(Request $request, Closure $next)
    {
        // Take the first language from the Accept-Language header
        $accept = Str::of($request->header('Accept-Language', ''))
            ->before(',')
            ->replace('_', '-')
            ->lower()
            ->value();

        // Add user id if you want to separate caches per user
        $userId = auth()->id();

        $suffix = implode('|', array_filter([$userId, $accept]));
        if ($suffix !== '') {
            $request->attributes->set('responsecache.cacheNameSuffix', $suffix);
        }

        // Optional: add a debug header so you can see what suffix is being used
        $response = $next($request);
        if ($suffix !== '') {
            $response->headers->set('X-ResponseCache-Suffix', $suffix);
        }

        return $response;
    }
}

Registering the Middleware

In Laravel 12, add it globally in bootstrap/app.php:

use App\Http\Middleware\SetResponseCacheSuffixFromLanguage;
use Illuminate\Foundation\Configuration\Middleware;

return Application::configure(basePath: dirname(__DIR__))
    ->withMiddleware(function (Middleware $middleware) {
        $middleware->append(SetResponseCacheSuffixFromLanguage::class);
    })
    ->create();

Now the cache key varies by Accept-Language and you no longer serve Arabic users the English version of your API.

Adding the Vary Header

If you’re running behind AWS ALB or a CDN, make sure your responses include Vary: Accept-Language. Otherwise proxies and browsers might serve the wrong cached version.

Just drop this into the middleware:

$response->headers->set(
    'Vary',
    trim(($response->headers->get('Vary') ?: '') . ', Accept-Language', ', ')
);

Don’t Forget to Clear Old Cache

The existing cache entries are language-agnostic, so clear them once:

php artisan responsecache:clear

How to Prove It Works

Run these two curls and check the header:

curl -H 'Accept-Language: en' https://api.example.com/v1/pages -I | grep X-ResponseCache-Suffix
curl -H 'Accept-Language: ar' https://api.example.com/v1/pages -I | grep X-ResponseCache-Suffix

You should see en vs ar. That’s your proof the cache is now language-aware.

Will be chasing Spatie's team to add this to the package as well, fingers crossed!

Check my personal blog for more tech-related content.

Forem: Dawid Makowski

Laravel Response Cache Serving Wrong Language: Fixing spatie/laravel-responsecache with mcamara/laravel-localization

The Problem: Laravel Multilingual Site Cache Stuck on Wrong Language

Our Multilingual Laravel Stack

Root Cause: Why spatie/laravel-responsecache Ignores the Locale

1. useAcceptLanguageHeader Overrides URL Locale During Route Resolution

2. Spatie's DefaultHasher Doesn't Include Locale in the Cache Key

3. Synchronous Artisan::call() in Model Observers Mutates Locale State

The Fix: Three Changes to Make Laravel Response Cache Locale-Aware

Fix 1: Custom Locale-Aware Hasher for spatie/laravel-responsecache

Fix 2: Disable useAcceptLanguageHeader in mcamara/laravel-localization

Fix 3: Move Sitemap Generation to a Queued Job

How to Check If Your Laravel App Is Affected

Don't Forget: Clear Response Cache After Deploy

Vibe Code Rescue: Turn Your AI-Built Prototype Into a Product That Can Actually Scale

Who this is for

What "vibe coded" really leaves behind

The Vibe Code Rescue, step by step

Week 1: See the truth

Week 2: Get a plan you can actually execute

What you walk away with

Why A2Z WEB

The "no surprises" guarantee

Frequently asked questions

Ready to find out what your product is really made of?

Smarter Scoring, Sharper Hiring: A Major Update to the CV Match Score API

TL;DR

The problem we were solving

✨ What's new

1. A formal directive contract for the context parameter

2. context now moves the overall_match score

3. Role-family standard credentials are now credited

4. Formalised 5000-character limit on context

Recommended patterns

Pattern 1 — Entry-level / fresher hiring

Pattern 2 — Senior technical hiring

Pattern 3 — Leadership / management hiring

Pattern 4 — Remote-first hiring

Best practices

⚠️ What context can and can't do

A full request example

A word on non-determinism

Get started

Your AI API, your rules: Introducing Custom AI Job instructions

The problem with one-size-fits-all AI

How it works

What this looks like in practice

What you can customize

Managing your prompts

What this means for teams and integrators

Get started

The Cloud Is Just Someone Else's Computer. Sometimes That Computer Gets Hit by a Drone.

When "Multi-Region Strategy" Means "Outrunning a Military Conflict"

Disaster Recovery Used to Mean Hurricanes. Now It Means Drones.

There's No Terraform Module for Surviving a War Zone

We're a Software Company. Why Do We Keep Running From Wars?

The Strangest Plot Twist of 2026

Who Else Is Living This?

The New Normal (Which Is Not Normal At All)

Introducing Custom Workflows: Turn Any AI Prompt Into a Production API

The Problem: AI Integration Is Still Too Hard

How It Works: A 5-Step Visual Builder

What You Get: A Real API, Not a Toy

Type Safety Without the Boilerplate

Real-World Use Cases

SDKs for Every Stack

Pricing: No Surprises

The Numbers

Get Started

You Just Gave OpenClaw the Keys to Your Entire Digital Life - on a VPS Server You Don't Know How to Secure

Step 0 - Non-root user

Step 1: Set Your Timezone

Step 2: Update Everything

Step 3: Set Up Ubuntu Pro

Step 4: Lock Down SSH

Step 5: Install Fail2Ban

Step 6: Set Up Two-Factor Authentication

Step 7: Monitor Your Logs

Bonus Round: For the Ambitious

Tailscale

1. `useAcceptLanguageHeader` Overrides URL Locale During Route Resolution

2. Spatie's `DefaultHasher` Doesn't Include Locale in the Cache Key

3. Synchronous `Artisan::call()` in Model Observers Mutates Locale State

Fix 1: Custom Locale-Aware Hasher for `spatie/laravel-responsecache`

Fix 2: Disable `useAcceptLanguageHeader` in `mcamara/laravel-localization`

1. A formal directive contract for the `context` parameter

2. `context` now moves the `overall_match` score

4. Formalised 5000-character limit on `context`

⚠️ What `context` can and can't do