- How do I install orhanerday/open-ai in a Laravel application?
- Install it with Composer using composer require orhanerday/open-ai. It is PSR-4 autoloaded and framework-agnostic, so no registration step is required to get started. Instantiate Orhanerday\OpenAi\OpenAi with your API key and call the endpoint method you need. From there you can wrap the client in a small service class and inject it wherever it is needed.
- Which Laravel and PHP versions does orhanerday/open-ai support?
- The package is compatible with Laravel 9, 10 and 11 on PHP 8.1 and above, and it has no notable conflicting transitive dependencies. Because it does not register a service provider, Laravel version bumps rarely affect it directly. Your real compatibility risk is OpenAI API drift rather than the framework version.
- Does this package include a Laravel service provider, facade or config file?
- No. orhanerday/open-ai is not a Laravel package in the framework sense: there is no service provider, no publishable config and no facade. The recommended pattern is to create your own LlmServiceProvider, bind an LlmClient interface to a thin OpenAiAdapter, and publish a config/llm.php file for the API key, base URL, model defaults, timeouts and retry policy. Putting that adapter in place early turns a future vendor swap into a small change instead of a rewrite.
- How do I test code that uses orhanerday/open-ai in Laravel?
- Testing is the main friction point: the client uses cURL rather than Laravel's HTTP client or PSR-18, so Http::fake() will not intercept its requests. The practical approach is to depend on your own interface, such as an LlmClient contract, and fake that in tests. If you need to exercise the adapter itself, stand up a local stub HTTP server and point the base URL at it. Accept this constraint up front rather than discovering it after the first test suite fails.
- Which OpenAI endpoints does orhanerday/open-ai cover?
- The SDK exposes chat, completions, embeddings, images, audio, files, fine-tuning and moderation through a fluent method-per-endpoint interface. Streaming is available through a callback. It is a thin wrapper over the REST surface, so anything beyond these, such as tool-calling orchestration or Assistants threads, means passing raw payloads and managing state yourself. Check the endpoints you actually need for the next 12 months before committing.
- How do I stream chat completions with orhanerday/open-ai?
- Streaming is supported by passing a callback to the chat method, which receives chunks as they arrive from OpenAI. In a Laravel app you would typically return a streamed response from your controller and forward the chunks through it. Keep in mind that you own the surrounding concerns: SSE handling, timeouts, mid-stream error handling, token accounting and logging. None of that is provided by the package.
- How should I handle errors and responses from this SDK?
- Responses come back as arrays or JSON strings with HTTP status codes surfaced loosely, so error handling defaults to inspecting the result and hoping you checked the right key. That produces silent failures in production if you do not wrap it defensively. Add a decorator or response mapper that converts results into typed DTOs and throws on non-success statuses with a structured error taxonomy. Downstream code should never need to know about raw OpenAI payloads.
- What does it take to make orhanerday/open-ai production-ready?
- The first call is one or two days of work; the surrounding eighty percent is not. Budget two to three engineer-weeks for key management, timeouts, retry with backoff, rate-limit handling, token accounting, PII-redacted logging, streaming over SSE, metrics and circuit breaking. Those belong in a decorator layer around the client, since the package provides none of them. If the feature is customer-facing or revenue-critical, that hardening work is mandatory rather than optional.
- How does orhanerday/open-ai compare with openai-php/client or multi-provider options?
- It is lighter and more informal than typed alternatives such as openai-php/client, and it offers no multi-provider routing, typed response objects or assistant/thread state management. If Azure OpenAI, Anthropic or Bedrock is on your roadmap within two quarters, put your own LlmClient interface in front of whichever SDK you choose. That way the package becomes one adapter and switching providers is a swap-out exercise. Choose it for narrow, synchronous, single-provider features such as chat plus embeddings.
- Is orhanerday/open-ai safe to depend on long term?
- It is a community-driven, single-maintainer project at roughly 2.4k stars with no SLA, no security advisory process and no vendor backport commitment. Recent releases are a positive signal, but cadence has historically been uneven against a fast-moving upstream API, and every OpenAI deprecation becomes your upgrade ticket. Mitigate by pinning the version, keeping the SDK behind your own interface, and confirming you can fork or vendor it if maintenance stalls. For regulated or revenue-critical paths, treat that as a governance decision rather than a detail.