- How do I install pixelpeter/laravel-genderize-api-client?
- Install it with Composer: composer require pixelpeter/laravel-genderize-api-client. The service provider and the Genderize facade alias are registered through Laravel package auto-discovery, so no manual provider registration is needed. Note that the current major requires Laravel 12.61.1 or newer (or Laravel 13) on PHP 8.3 or newer, so verify your platform before running the require command.
- Which Laravel versions does this package support?
- Version 13.x supports Laravel 12 from 12.61.1 onward and Laravel 13.x, because the framework constraint is ^12.61.1|^13.0. That floor deliberately excludes Laravel 12 releases affected by the CRLF injection and temporary signed URL advisories. Laravel 10 and 11 support was dropped in v13, so older applications must stay on the deprecated v12.0.0 line or upgrade the framework first.
- What PHP version does laravel-genderize-api-client require?
- The v13 line requires PHP 8.3 or newer; PHP 8.1 and 8.2 were dropped and the supported range is effectively 8.3, 8.4 and 8.5. This matters because Laravel 12 still runs on PHP 8.2, so an application on Laravel 12 plus PHP 8.2 must bump PHP before it can take the package upgrade. Check CI images and queue worker containers too, since they often lag behind local dev.
- How do I detect gender from a first name using the Genderize facade?
- Resolve the Genderize facade in your controller, job or service class and pass a first name to the client method documented in the package README; the facade proxies to the underlying HTTP client bound in the container. The response gives you the guessed gender alongside probability and sample count, which you can use to enrich a user profile or prefill a form. Keep the call outside your request-critical path if you want to avoid blocking on a third-party service.
- How do I configure the package and supply a Genderize.io API key?
- Publish the package config file with the vendor:publish Artisan command and adjust it to your environment. That published file is where you set your optional Genderize.io API key, which raises your rate limit, along with any client settings the package exposes. Keep the key in your .env file rather than in version control, as you would with any other third-party credential.
- Why does my Woocommerce facade alias fail after upgrading to v13?
- Earlier versions registered the discovered facade alias incorrectly as Woocommerce; v13 fixes it to Genderize. Code referencing Woocommerce, or a manual Facade::alias or class_alias registration you added to work around it, will fail at resolve time rather than at install time. Grep your codebase for Woocommerce, switch the import and usage to Genderize, and remove any manual alias registration.
- What does the version number ^13.0 mean for this package?
- The package's major version tracks the highest Laravel major it supports, so ^13.0 means Laravel 13 support rather than the thirteenth release of the package. This is a permanent convention change, so document it in your upgrade notes to avoid confusion during future bumps. Also note that v12.0.0 is deprecated and will not receive further releases, so applications still on Laravel 10 or 11 have no forward path except a framework upgrade.
- How do I test code that calls the Genderize API without hitting the live service?
- Because the package is a thin wrapper around Laravel's HTTP client, Http::fake() is the usual way to stub responses in feature and unit tests; check the package source to confirm the request goes through the Illuminate HTTP factory. Fake a typical payload with a name, gender, probability and count so your assertions cover the real response shape. The package's own test suite runs on orchestra/testbench with PHPUnit 12, which is a good indicator of current Laravel testing practice.
- What fields does the Genderize.io response contain and how reliable is the prediction?
- The upstream API returns the queried name, a gender value, a probability, and a count representing how many records the prediction is based on. Treat low probability or a small count as inconclusive rather than as a firm answer, and store the raw values so you can re-evaluate later. Because predictions are statistical guesses, avoid using them for automated decisions in sensitive areas such as hiring or credit.
- What happens in production if Genderize.io is slow, down, or rate limited?
- Treat the service as unreliable by default: wrap the call in a try/catch, apply a short timeout, and degrade gracefully so name-based detection never blocks a form submission or profile save. Cache results per first name to cut call volume, stay inside rate limits, and give repeated lookups the same answer. If you store inferred gender, also check your privacy obligations, since inferring gender from a name is personal data in many jurisdictions.