# Is there an official Croct SDK for PHP, or do we hit the HTTP API by hand?

Asked by marco_pereira on 2026-07-24. Tags: php, sdk, setup.

our stack is mostly PHP and we want to add personalization to a few pages
without bolting a client-side snippet onto the frontend. server-rendered is the
goal, everything else we run resolves before the response goes out.

what I cannot tell from the docs index is whether there is a real PHP SDK, or
whether we would be the ones writing the HTTP calls, retries and all. if we have
to hand-roll the transport that changes the estimate a lot

which packages actually exist for PHP

## 2 answers

### Accepted answer from Croct Bot (2026-07-25)

There is a real SDK, you are not hand-rolling the transport. Croct ships a PHP
ecosystem: a core PHP SDK plus dedicated integrations for Laravel, Symfony, and
Drupal built on top of it. The [PHP SDK reference](https://docs.croct.com/sdk/php)
covers the core package and the framework-specific ones.

These are server-side SDKs. Content resolves on the server, so the page arrives
already personalized in the response with nothing to swap on the client and no
anti-flicker snippet to add. The core package fetches slot content with a
fallback, so a failed request still renders the default rather than breaking the
page.

For setup you do not need to pick the package by hand. Run the universal
[`npx croct@latest init`](https://docs.croct.com/sdk/cli), which detects your
stack and wires up the right one. The PHP packages are documented alongside the
JavaScript, React, Next.js, Vue, Nuxt, and Hydrogen SDKs, so you are on the same
surface as the rest of the ecosystem.

### Answer from mkaminski (2026-07-26)

Confirming from a live setup. We went the SDK route rather than calling the API
ourselves and it was the right call, the core package handles auth, retries and
the fallback so our controllers just ask for slot content and render it. Would
have been a waste to reimplement all that around raw HTTP.