Projects

A project is Storelayer’s isolation boundary. Customers, wallets, rules, resources, promotions, referrals, integrations, custom storage, and API keys all belong to one project, and nothing is shared between projects. Project IDs look like prj_ab12cd34ef56.

Project config

GET /projects/{projectId}/config returns:

{ "success": true, "data": { "currency": "USD", "timezone": "UTC", "settings": {} } }

Field	Default	Meaning
`currency`	`USD`	The project’s currency code
`timezone`	`UTC`	The project’s timezone
`settings`	`{}`	Free-form key/value object for your own configuration

Update with PATCH /projects/{projectId}/config; send only what changes:

{ "currency": "EUR", "timezone": "Europe/Berlin", "settings": { "pointsPerEuro": 10 } }

settings is merged one level deep: top-level keys you send replace those keys; keys you omit are kept. To change a nested object, send the whole object for that key.

Project timezone does not drive promotion time conditions. Promotion evaluation reads the IANA timezone from the cart (context.timezone) and uses UTC when it is missing; pass it on every evaluate call if you have day-of-week or hour-based promotions. See creating promotions.

Environments

There is no environment flag inside a project. Use separate projects for development, staging, and production, each with its own API keys. Keep the project ID and its key together in each environment’s configuration so a dev deployment can never write to production wallets.

Moving rules between projects

Build and test rules in a staging project, then copy them:

curl -s -X POST "https://api.storelayer.io/projects/prj_staging/clone-to/prj_production" \
  -H "Authorization: Bearer $SL_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "ruleIds": ["<ruleId>"], "includeResources": true }'

Body field	Default	Behavior
`ruleIds`	all rules	Omit or send `[]` to clone every rule
`includeResources`	`true`	Also copies the resources those rules reference, plus their dependencies

What to expect:

Cloned rules are always created inactive in the target. Review and activate them deliberately.
Cloning creates new rules each time; running it twice gives duplicates.
A resource whose key already exists in the target is skipped, not overwritten (created: false). If the target’s version differs, update it separately.
Response (201): data.rules, data.resources ({ sourceKey, created }), and data.summary (rulesCloned, resourcesCreated, resourcesSkipped).
Only rules and resources are cloned — not promotions, wallets, customers, config, or API keys.

The request is authorized against the source project in the path. An API key belongs to a single project, so cross-project cloning is normally done with a dashboard session.

Team roles

Dashboard users are project members with one of three roles:

Role	Can
`owner`	Everything, including deleting the project, transferring ownership, changing roles, removing members
`admin`	Invite members and manage invitations, plus all project operations
`member`	Project operations (rules, promotions, wallets, …)

Invitations assign admin or member; each project has one owner. API keys act outside this role system — a key can do anything a project API call allows. Team management lives under Team in the API reference.

Pitfalls

Inspect config, existing rules, and resources before extending a program — another integration may already award points for the same event.
Projects are created from the dashboard (or with a dashboard JWT); an API key cannot create projects.