Configuration

Each package has its own config file (odden-core, odden-sales), published with php artisan vendor:publish --tag=odden-<package>-config. This page covers the settings that work the same way across all of them. Module-specific options are documented in each module's section.

The user model#

Odden links records to people on your team: deal owners, activity authors, and, with the paid add-ons, ticket assignees. It uses your application's user model for this, resolved in this order:

1. odden-core.user_model, set with the ODDEN_USER_MODEL environment variable
2. Your default auth provider's model (auth.providers.users.model)

ODDEN_USER_MODEL=App\Models\Admin

The model only needs to be an Eloquent model. Where Odden shows a person's name, it reads the model's name attribute.

Public routes#

Sales registers routes for the things your customers use directly, such as quote acceptance and booking pages. The paid Marketing and Service add-ons do the same for hosted forms, landing pages, tracking links, the support portal and the help center, in the same way. Each module has a routes block you can adjust:

// config/odden-sales.php
'routes' => [
    'enabled' => (bool) env('ODDEN_SALES_ROUTES_ENABLED', true),

    // Pages people visit: quote acceptance and booking pages.
    'web' => [
        'domain' => env('ODDEN_SALES_DOMAIN'),
        'prefix' => env('ODDEN_SALES_PREFIX', ''),
        'middleware' => ['web'],
    ],
],

• Set enabled to false to register none of a module's routes, for example if you build your own pages on top of its actions.
• Use domain to serve a module's pages from a subdomain, such as help.example.com.
• Use prefix to move them under a path, such as crm, if they clash with your own routes.

Route names stay the same whatever the prefix or domain (for example odden.quotes.show), so generate links with route() rather than hard-coding paths.

Endpoints that other sites or servers post to, such as embedded forms, the chat widget, tracking, and webhooks, are exempt from CSRF verification. Everything else uses the middleware you configure.

API tokens#

Server-to-server endpoints that a module adds (for example the inbound webhooks and sending APIs of the paid Marketing and Service add-ons) are protected by a shared token per module, set in an environment variable named in that module's documentation:

ODDEN_MODULE_API_TOKEN=a-long-random-string

These endpoints fail closed: until a token is configured they respond with 403. A request with a missing or wrong token gets 401. The token can be sent in any of these ways, so you can use whichever the calling service supports:

# Bearer token
curl -X POST https://example.com/api/module/endpoint \
  -H "Authorization: Bearer $ODDEN_MODULE_API_TOKEN" -H "Accept: application/json" ...

# Custom header
curl ... -H "X-Odden-Token: $ODDEN_MODULE_API_TOKEN"

# Query string, for providers that only accept a webhook URL
# (only on routes that opt in; Odden's provider webhooks do)
https://example.com/api/module/webhook?token=...

Prefer a header: query strings can end up in access logs. Each module's pages say which of its endpoints need the token.

Rate limits#

Odden registers three rate limiters, keyed by IP address and module, and applies them to its public routes. Each module (the first two segments of the route name, such as odden.service or odden.marketing) has its own counter, so using chat does not count against a marketing form:

Both live in odden-core.rate_limits. If your application runs behind a load balancer or CDN, configure trusted proxies so the limits apply per visitor rather than to the proxy's address.

Core settings#

Other options in config/odden-core.php:

See Core concepts for how these behave.