Several options exist that allow you to configure the behavior of the Raven_Client. These are passed as the second parameter of the constructor, and is expected to be an array of key value pairs:

$client = new Raven_Client($dsn, array(
    'option_name' => 'value',

Available Settings

The following settings are available for the client:


A string to override the default value for the server’s hostname.

Defaults to Raven_Compat::gethostname().


An array of tags to apply to events in this context.

'tags' => array(
    'php_version' => phpversion(),
    'php_version' => phpversion(),

The version of your application (e.g. git SHA)

'release' => MyApp::getReleaseVersion(),

The environment your application is running in.

'environment' => 'production',

The root path to your application code.

'app_path' => app_root(),

Paths to exclude from app_path detection.

'excluded_app_paths' => array(app_root() . '/cache'),
$client->setExcludedAppPaths(array(app_root() . '/cache'));

Prefixes which should be stripped from filenames to create relative paths.

'prefixes' => array(

A function which will be called whenever data is ready to be sent. Within the function you can mutate the data, or alternatively return false to instruct the SDK to not send the event.

'send_callback' => function($data) {
    // strip HTTP data
$client->setSendCallback(unction($data) {
    // dont send events if POST
    if ($_SERVER['REQUEST_METHOD'] === 'POST')
        return false;

Defaults to ‘sync’.

Available methods:

  • sync (default): send requests immediately when they’re made
  • async: uses a curl_multi handler for best-effort asynchronous submissions
  • exec: asynchronously send events by forking a curl process for each item

Defaults to ‘curl’.

Specify the path to the curl binary to be used with the ‘exec’ curl method.


Set a custom transport to override how Sentry events are sent upstream.

'transport' => function($client, $data) {
        'url'     => $client->getServerEndpoint(),
        'method'  => 'POST',
        'headers' => array(
            'Content-Encoding' => 'gzip',
            'Content-Type'     => 'application/octet-stream',
            'User-Agent'       => $client->getUserAgent(),
            'X-Sentry-Auth'    => $client->getAuthHeader(),
        'body'    => gzipCompress(jsonEncode($data)),

Set this to false to disable reflection tracing (function calling arguments) in stacktraces.


Adjust the default logger name for messages.

Defaults to php.


The path to the CA certificate bundle.

Defaults to the common bundle which includes ./data/cacert.pem


  • The CA bundle is ignored unless curl throws an error suggesting it needs a cert.
  • The option is only currently used within the synchronous curl transport.

The SSL version (2 or 3) to use. By default PHP will try to determine this itself, although in some cases this must be set manually.


Defaults to 1024 characters.

This value is used to truncate message and frame variables. However it is not guarantee that length of whole message will be restricted by this value.


An array of classes to use to process data before it is sent to Sentry. By default, Raven_SanitizeDataProcessor is used


Options that will be passed on to a setProcessorOptions() function in a Raven_Processor sub-class before that Processor is added to the list of processors used by Raven_Client

An example of overriding the regular expressions in Raven_SanitizeDataProcessor is below:

'processorOptions' => array(
    'Raven_SanitizeDataProcessor' => array(
                'fields_re' => '/(user_password|user_token|user_secret)/i',
                'values_re' => '/^(?:\d[ -]*?){15,16}$/'

Providing Request Context

Most of the time you’re not actually calling out to Raven directly, but you still want to provide some additional context. This lifecycle generally constists of something like the following:

  • Set some context via a middleware (e.g. the logged in user)
  • Send all given context with any events during the request lifecycle
  • Cleanup context

There are three primary methods for providing request context:

// bind the logged in user
$client->user_context(array('email' => ''));

// tag the request with something interesting
$client->tags_context(array('interesting' => 'yes'));

// provide a bit of additional context
$client->extra_context(array('happiness' => 'very'));

If you’re performing additional requests during the lifecycle, you’ll also need to ensure you cleanup the context (to reset its state):