Laravel Resume Parser Laravel Package

Product Decisions This Supports

• Build vs. buy for resume ingestion: This package is the thin Laravel integration layer over SharpAPI's hosted resume parser. It lets you evaluate "buy the parsing engine, build only the product surface" rather than staffing an in-house CV/resume extraction pipeline (OCR, section segmentation, entity normalization, multi-format handling). The v1.1.0 hardened error paths make this a viable low-commitment pilot.
• Roadmap: candidate/application intake features. Suitable to scope features like bulk resume upload, structured candidate profiles, ATS-style search filters, and skills/experience normalization — the package handles async job dispatch and result retrieval so your team builds product UX, not parsing internals.
• Reliability and supportability decisions. Two v1.1.0 fixes materially change operational risk: polling-interval config is now actually honored (cost/latency tuning becomes real), and failed jobs with null results return a SharpApiJob instead of throwing a TypeError, while a missing API key raises a clear InvalidArgumentException. These are the difference between "unpredictable production failures" and "diagnosable error states" — relevant to SLA commitments and on-call burden.
• Developer velocity / AI-assisted delivery. Shipping Laravel Boost resources (a core guideline plus a sharpapi-resume-parser skill) means AI coding assistants in a Laravel codebase get package-specific guidance. That is a tangible onboarding-cost reduction for teams already using Boost-assisted workflows.
• Quality-confidence signal for procurement. A Pest + Orchestra Testbench suite is first-party automated test coverage on a package that sits in a data path. This weakens the "unmaintained wrapper" objection in vendor review.
• Cost/latency modeling. Because polling is now configurable in practice, you can choose between API-driven Retry-After pacing and fixed-interval polling — a direct lever on throughput, rate-limit behavior, and perceived responsiveness in async UX (e.g., "we're still parsing your resume" states).

When to Consider This Package

Adopt when:

• The product is Laravel/PHP and you want native integration (service provider, config publishing, job dispatch) instead of hand-rolling HTTP calls to a parsing API.
• Resume/CV parsing is a supporting capability, not the core differentiator — you want time-to-market on the feature, not ownership of extraction models.
• You need asynchronous processing of documents with retrievable job status, which fits upload-then-poll UX patterns typical of applicant flows.
• You are running (or trialing) Laravel Boost / AI-assisted development and value curated, package-aware guidance and skills.
• You are at pilot or MVP stage and want a dependency with tests and explicit error semantics before committing to volume.

Look elsewhere or defer when:

• You require data residency, on-prem, or strict PII handling that forbids sending resumes to a third-party API — this is a hosted-service wrapper, not a self-contained parser.
• You need full control over extraction logic (custom ontologies, proprietary scoring, domain-specific normalization) that a vendor API will not expose.
• You are not on Laravel — the value here is largely the framework integration; a plain SDK would be a better fit.
• You need hard throughput/availability guarantees and cannot accept an external dependency plus the polling model as your ingestion backbone.
• You expect long-term maintenance certainty: note the release still requires a minimum sharpapi/php-core version, so you inherit a transitive dependency's behavior; verify the core package's release cadence and support policy before standardizing.

How to Pitch It (Stakeholders)

For executives (one paragraph): This release turns a promising integration into a supportable one. We can add resume parsing to our Laravel product without building or maintaining a document-extraction pipeline ourselves — the vendor handles parsing, we own the experience. The v1.1.0 changes are mostly about trust: configuration we expose now actually takes effect, failures surface as clear, handleable errors instead of crashes, and the package ships with an automated test suite. Combined with built-in guidance for AI-assisted development, it lowers both our initial build cost and our ongoing on-call risk. Recommendation: green-light a bounded pilot behind a feature flag, with the vendor API treated as an external dependency in our architecture and a documented exit path.

For engineering (summary): Upgrade to v1.1.0 and pin sharpapi/php-core ^1.4.1. Two behavioral changes to design around: (1) SHARP_API_JOB_STATUS_USE_POLLING_INTERVAL=true now genuinely switches fetchResults() to poll at SHARP_API_JOB_STATUS_POLLING_INTERVAL rather than honoring the API's Retry-After — audit any polling config you assumed was inert, and pick one pacing strategy deliberately; (2) failure handling is now typed — a failed job with a null result returns a SharpApiJob rather than raising a TypeError, and a missing API key throws InvalidArgumentException. Update job handlers and tests to branch on job state and catch the configuration exception at startup rather than relying on generic error handling. New Pest + Orchestra Testbench coverage and Laravel Boost resources (core guideline plus the sharpapi-resume-parser skill) give us a testable baseline and better AI-assistant context; verify the suite runs clean in our CI before rollout, and confirm secret management so the missing-key path never reaches production.