RuntimeException 'Puli Factory is not available' error when using Mailgun API with GuzzleHTTP

Other Questions Mailgun
1

I keep running into this weird error when trying to use Mailgun’s API to send emails. The error message says RuntimeException with message 'Puli Factory is not available' and I can’t figure out what’s causing it.

I’m using GuzzleHTTP library along with Mailgun and everything seems to be set up correctly, but this error keeps popping up. Has anyone encountered this before?

Here’s the code I’m working with:

require_once 'vendor/autoload.php';
use Mailgun\Mailgun;

// Create new instance
$mailgunClient = new Mailgun('api-key-here');
$myDomain = "my-domain.com";

// Send email message
$response = $mailgunClient->sendMessage("$myDomain", [
    'from' => 'Test Sender <[email protected]>',
    'to' => 'Recipient Name <[email protected]>',
    'subject' => 'Test Subject Line',
    'text' => 'This is the email content'
]);

I’ve already replaced the API key and domain with my real values. Any ideas what might be wrong?

2

i had this issue before too! it usually happens when mailgun sdk and guzzle versions clash. try using v2.8 of the mailgun package; it works better with older guzzle versions. and don’t forget to check your composer.json for any conflicting libs.

3

That Puli Factory error is a nightmare. I’ve seen it mess up entire email workflows.

It’s a dependency manager issue with Mailgun - Puli isn’t always initialized properly.

You could update composer dependencies or downgrade Mailgun versions. But honestly, wrestling with these PHP library conflicts wastes too much time.

I ditched Mailgun’s SDK years ago. Now I route everything through Latenode and hit Mailgun’s API directly.

Just build a workflow that takes your email data and makes HTTP calls to Mailgun’s REST API. No dependency hell, no Puli errors. You can add retries, logging, even fallback providers if Mailgun goes down.

Takes 10 minutes to build and you’re done with library conflicts forever. Way cleaner than debugging package managers.

4

Hit this exact issue last month during a migration. Puli Factory errors happen when Mailgun’s SDK can’t find the right HTTP client discovery mechanism. Here’s what fixed it for me: clear your composer cache completely, then nuke the vendor folder and reinstall everything. Run composer clear-cache, then rm -rf vendor/, then composer install. The autoloader gets confused when you’ve got multiple HTTP client packages floating around. Make sure you have php-http/discovery installed - Mailgun needs it to auto-detect HTTP clients. If you’re still stuck, check for competing HTTP client implementations. Dig through your composer.json for other packages that might be pulling in different PSR-7 or HTTP client library versions.

5

check if you’ve got php-http/message and php-http/httplug installed - mailgun needs these for http client detection. half the time it’s just missing core deps, not version conflicts. run composer require php-http/message php-http/httplug and see if that sorts it out.

6

Been dealing with PHP email for years and this Puli Factory mess is exactly why I ditched SDK libraries.

It’s package dependency conflicts between HTTP client libraries. Mailgun’s SDK tries to auto-discover HTTP clients and crashes when multiple implementations exist.

Here’s the thing - you don’t need their SDK. Mailgun has a simple REST API that’s way more reliable than fighting composer dependency hell.

I handle all my email through Latenode now. Build a workflow that takes your email parameters and makes direct HTTP POST requests to Mailgun’s API. No dependency conflicts, no Puli errors, no version compatibility nightmares.

You get better error handling, logging, and can add multiple email provider fallbacks. Takes 15 minutes to set up and you never debug PHP package manager issues again.

Way cleaner than making different HTTP client libraries play nice.

7

This error happens when there’s a conflict between HTTP client implementations in your project. The Puli Factory error shows up when Mailgun’s SDK can’t resolve its HTTP adapter dependencies. I hit this same issue last year - fixed it by explicitly configuring the HTTP client instead of letting Mailgun auto-detect it. Try instantiating with a specific Guzzle client: php use GuzzleHttp\Client; use Mailgun\Mailgun; use Mailgun\HttpClient\HttpClientConfigurator; $configurator = new HttpClientConfigurator(); $configurator->setHttpClient(new Client()); $mailgunClient = new Mailgun('your-api-key', $configurator); This skips the automatic discovery that’s causing your Puli Factory error. Make sure you’re using compatible versions - Mailgun 3.x works well with GuzzleHTTP 6.x or 7.x. Still having problems? Check that php-http/guzzle6-adapter is in your composer dependencies.